MySQL A Threat to Bigwigs?

Disoculated writes "Is MySQL a threat to bigwigs? is the question asked in CNN's technology section. The article notes that MySQL is running perhaps 20% of the web databases but its revenue is merely 0.02%... yet the company is still making money and putting out an excellent product. Is this a sign that the database market is in for a drastic change? Of course, there's no mention of PostgreSQL or mSQL, but I guess that's typical."

Comments

Version 4 Will Tell

[Daveman692]

It all boils down to how MySQL 4 is looked upon. Big sites already use MySQL, as seen here, but will version 4 have enough features, be robust enough, and provide the support to convince those running things such as Oracle to switch.

Re:Version 4 Will Tell

[letxa2000]

I think the issue is that MySQL is very adequate for 99% of all users including most large enterprises and certainly most websites. Even if it is adequate for only 90% of them it's a huge threat to the big guys. There will always be a niche for the big guns that handle huge databases with many, many simultaneous updates. But that's a small fraction of the total universe of database installations and I don't think it's enough for the big guys to continue to be profitable.

Re:Version 4 Will Tell

[walt-sjc]

Let me expand on that :-)

The bottom line is that Oracle (and other enterprise DBs like MSSQL, DB2) have enterprise features that MySQL (and other open source DB's) just don't have, and probably won't have for Years. It's more than just the ability to scale, and raw performance on simplistic tables.

Most everyone is very much aware of MySQL and other open source solutions are great for certain types of applications, but horrible for others.
That said, many enterprise users use Oracle in cases where MySQL would be much more cost effective, and probably better performing as well.

Re:Version 4 Will Tell

[captaineo]

I agree that 90% of people who use databases would really be better off with simple text files or an in-memory server... SQL is overkill for shopping lists and username lists, though it certainly makes sense for high-end, high-performance stuff.

ReiserFS is trying to become a database. The first step was making ReiserFS v3 perform well on small files. (the idea is to store tree-like/XML-ish data in a directory structure where each file contains only a few bytes of data). Last I heard, ReiserFS v4 was moving towards a full transaction API that will allow atomic batch transactions on more than one file in a single system call. (aside from the space overhead problems inherent with storing tiny amounts of data in each file, most current filesystems don't allow atomic transactions that involve more than one write to one file...)

Re:Version 4 Will Tell

[-eddy]

If a DB was integrated into the OS as the preferred method of storing data...

Isn't that what Microsoft calls the Registry?

Re:Version 4 Will Tell

[JPriest]

You mean like Longhorn's SQL based WinFS?

Re:Version 4 Will Tell

[Anonymous Coward]

There are two camps of thinking on this: the flat file people, and the relational database people. I think I'm from somewhere in between.

Much of the time, someone starts working with flat files and ends up wasting a lot of time writing, testing and debugging code that simply does the file handling work. Sure, a database may be considered "overkill" for some tasks, but most of the time it's worth it just for the time you save not worrying about that extra layer.

Plus, it is a heck of a lot easier later on to:

- modify the database schema. eg. Even if your specific program doesn't need additional columns, you can add some which will be used by another program. XML can help alleviate some of that, but it's bloated so using a database instead really isn't really any more overhead.

- multiple user access

- security!

- easy to backup/restore

- ACID properties

- multi-language support

- so the next person to be in your position will know what the hell is going on. :)

- tons of other things you'll say "oh yeah" about down the road when your flat file system code doesn't cut it anymore.

Where are flat files good? Client application settings, documents to exchange with users, simple and single-user data.

Re:Version 4 Will Tell

[skillet-thief]

Yes, version 4 will be an improvement, BUT it is still missing many key features like views, triggers, full outer joins, update with subselect, that are already present in Postgres, and the fact is I've been using the features that MySQL is promising for the future for a year and a half now.

One thing that probably keeps a lot of users (esp. web people) loyal to MySQL, is the fact that they learned SQL on MySQL and don't really know what else it should be doing for them.

In fact, that is where I am right now: just realizing the limits of what MySQL can do and tired of writing various hacks via PHP or Perl to get around certain weaknesses.

But I think that a lack of SQL culture could keep many users locked into MySQL when other DBs might be better for them.

Re:Version 4 Will Tell

[jeremyp]

XML and SQL are designed for different jobs. XML is a language for describing structured data, nothing more, nothing less. SQL is a language for manipulating structured data in a flexible way. I see no reason why you couldn't issue an SQL query to a database and have it return the results as XML. Well, there is one problem: PHP (for instance) has a nice little function call that will take a row from the mysql result set and return it as an associative array indexed by the column names in native format. Other languages have equally simple ways to get the data in a usable form. Why mess around with XML parsers?

SQL comes into its own as soon as you have more than one logically distinct but related set of data. SQL allows you to query that data in arbitrary ways not necessarily catered for in the original design.

Further, XML is a poor way to store data unless you intend to read it all into RAM before doing anything to it. An XML file is essentially a stream of character data which means that it is difficult to index it (making searches slow), difficult to insert records into it (well you could just append new data thus making searches even slower) and not space efficient (lots of extraneous syntax which is only there to make it easier to export to other apps + binary data has to be stored encoded as character data in some way which invariably makes it bigger).

20K reasons why it is

[Crashmarik]

I LOVE MYSQL.
Its well integrated into just about every web development system you can name.

With PHP or perl you can roll out a small interactive site in less than a day.

At least you can figure out how much it costs. I can't say how much customers love hearing about ORACLES price by the system you install it on system.

Its not one of Microsofts line of swiss chese products that have more holes than a typical sieve. Slammer worm anyone ?

Oh yeah MYSQL is a threat. Software that works and a revenue model that depends on satisfied customers.

Crash

postgres, schmostgres...

[twiggy]

I don't see Postgres getting much media coverage until the syntax stops sucking.

I'm sure that a lot of uber programmer types are going to say "if you can't figure it out, you're a jackass", etc etc... but the bottom line is too much easy stuff is a pain in the ass to do, syntactically, with Postgres... Even auto incrementing IDs in Postgres are annoyingly difficult compared to MySQL...

I am well aware of the cool stuff that postgres does, but a lot of that cool stuff is only needed by people with specialized purposes.. your average blog site or even e-commerce site doesn't really need nested queries and all that stuff, so why go through all the syntactical annoyances when doing a simpler site?

When pg gets easier to use, i'll make the transition...

Re:postgres, schmostgres...

[the eric conspiracy]

Even auto incrementing IDs in Postgres are annoyingly difficult compared to MySQL...

Nah, they actually make much more sense in Postgres than they do in MySQL because you can access them using a standard query rather than some bozo non-standard driver extension as in MySQL.

The problem with MySQL is that the lack of basic functionality like triggers, subselects, foreign keys makes it a total PITA except for the simplest applications. Sure you can write code that works around the implementation limitations, but WHY should I have to reinvent something over and over that should BE PART OF THE DATABASE?

You may think this stuff is esoteric, and not needed for the average blog or even e-commerce site, but that's baloney. FKEYS *ARE* needed for just about *ANY* database application except the most trivial - ie. an address book.

MySQL - forget it - it just isn't competitive with other free databases out there.

Re:postgres, schmostgres...

[tzanger]

ie. an address book.

And even then, you should be using LDAP.

Re:If MySQL was just a bit more user-friendly...

[drudd]

Have you ever looked at MySQL's online documentation? It's wonderful...

Fully indexed, with user comments... I often find new techniques while searching for something completely unrelated. I think the great documentation is one of the reasons why MySQL has taken off, it's just so easy to learn.

Doug

Reason why PostgreSQL or mSQL weren't mentioned

[ciurana]

From the posting:

Of course, there's no mention of PostgreSQL or mSQL, but I guess that's typical.

This article has all the signs of being the effort of MySQL's PR firm. Nothing wrong with that; they didn't mention PostgreSQL or other OSS databases because their desired outcome is to increase awareness of MySQL, not the others.

Cheers!

E

Re:Reason why PostgreSQL or mSQL weren't mentioned

[leviramsey]

That is the way that things tend to work in the magazine world. In this case, since MySQL is not that big a fish, Fortune's editor tells some junior writer, "Forbes and BusinessWeek have run articles on open source software in business. Do something on open source databases." The junior writer then looks at the figures, sees that MySQL is the most popular of the OSS db's, sees that there's an actual company behind them, and calls up MySQL AB's press office. Said PR firm basically sends him an outline, with relevant quotes from luminaries, and junior writer bangs out a story from that outline.

Moral of the story: magazine writers are lazy.

web databases != database market

[Misha]

you probably won't find too many databases on the 'net that need the kind of performance some commercial brands give. so i wouldn't say the drastic change is coming, unless companies start putting their payroll records for the web to see.

our company actually puts mysql onto websites, but no client comes (at least for us) and says 'can you replace my blah-blah db version blah point blah with mysql'. we usually put mysql as a replacement for product databases, forums, etc. which previously were stored in text files or worse. and we usually do this for clients who simply can't afford anything and haven't invested into updating their site in 1-2 years. if they can afford it, they usually already know what they want, and it usually doesn't come free in a cvs snapshot.

Re:Ethical obligation?

[RevAaron]

Read what you put in bold again. This journalist said that they become ethically obliged- not legally by the GPL. And largely, that is the case. It would be nice if the writer could have said more than just that, but how could it have been said better in one sentence?

If you don't think that businesses (to a lesser extent, individuals) have an ethical obligation imposed by the community to share modifications made to an OSS project, you haven't been reading Slashdot or other forums of Free/OS software discussion. Hell, half of the "Ask Slashdots" where someone is asking about some whether application that does x, y, and z exists for Linux, there is always a big hunk of replies stating "this is OPEN sourze d00d write it yourself and share it with the world. otherwise, you don't deserve to use OSS- even if this app already existed." Yes, it's a stupid attitude (IMHO), but quite real in the community.

Who Wants To Be A Millionaire?

[jfisherwa]

Put a wrapper/installer around MySQL or PostgreSQL that lets you import a SQL Server database dump -- including stored procedures.

Re:If MySQL was just a bit more user-friendly...

[tuffy]

Fully indexed, with user comments... I often find new techniques while searching for something completely unrelated. I think the great documentation is one of the reasons why MySQL has taken off, it's just so easy to learn.

Furthermore, look at the dead-tree documentation available for each. Not only are there more MySQL books available than PostgreSQL ones, but the MySQL ones tend to be larger. For example, the New Riders MySQL book is over 400 pages longer than the PostgreSQL one - and their MySQL title isn't exactly brimming with filler. I'm convincesd PostgreSQL adoption will lag behind MySQL until more/better docs show up so people can learn it and its capabilities better.

Re:If MySQL was just a bit more user-friendly...

[harvardian]

Your comment is spoken from the point of view of somebody who runs a website with a small to moderately sized, simple database.

So that's great, you blog well in PHP, but you utterly overstate the power of MySQL. MySQL will not even approach taking on the big database apps until they have a) subqueries and b) true ACID support. Many complex websites have stored procedures with subqueries in them, and it's logistically impossible for these sites to migrate to MySQL, since it would involve rewriting anything with a subquery (if it's possible at all without nasty temp table hacks).

And not having ACID (atomicity, consistency, isolation, and durability, btw) support? No enterprise-level website, especially one that does eCommerce, would ever think of running a database without proper transactions.

So, yeah, MySQL is great at handling small- to mid-size loads, but once you get to high complexity or you need transactions, it's over. Maybe if they include this stuff in version 4 and it survives a couple of years of testing, THEN we might see some significant migration, but it will not happen until then.

MySQL vs "bigwigs"

[mabu]

Let's see, I can pay $14,000+ for an Oracle license, which involves a deliberately convoluted array of hoops to jump through, "education points", maintenance contracts, and product module/pricing options that would make most long distance plans seem trivial. If I need support I have a plethora of options with cool names like "bronze", "silver" and "gold" which in effect give me a varying scale of hours or days in which I can wait to have issues resolved.

Or I can pay $300 for a MySQL commercial license and if I have any problems or additional functionality there are thousands of web sites with tons of free advice and code. And MySQL will blow the doors off of Oracle and other databases in terms of raw speed. Advanced options like data warehousing, replication, fancy triggers, rollbacks and other systems can be sometimes better-integrated on a hardware/os level so it's arguable as to whether MySQL's lack of some features is even a negative. You get more with less all around with MySQL: better support, more rapid bug/security patches, less hardware requirements, and more people in the online community who are willing to help without charging you by the hour because of their pretentious DBA title.

Tough choice...

Mindshare

[arvindn]

MySQl being more popular than Postgres has a lot to do with mindshare than product quality. Take me, for instance. I set up apache for the first time a month ago, and I wanted a db server for some things. I had heard of both MySQL and Postgres, but I had been bombarded with the words "LAMP" and MySQL guide/tutorial/howto so many times in the past that my first thought was to give MySQL a try. I found it was already installed on my machine, had lots of documentation, and had no learning curve - no complaints at all. So, Postgres didn't even get a fair consideration from me. Of course, you might say that newbies and students like me don't count, but keep in mind that I might become a database admin some day, at t which point I would have a lot more experience with MySQL than Postgres...

Re:Mindshare

[rtaylor]

With all due respect, you're not going to make a very good database admin if your experience is limited to MySQL.

Much as I wouldn't hire someone who's sole unix experience was with Linux (for any position other than Junior anyway). You simply learn a slew more tricks of the trade when your experience is diversified. When making a decision, you can usually back it up with a decent reason rather than simply "It's what I'm used to".

Nothing against Linux or MySQL. I've said the same to people who have solely used Oracle on Solaris.

transactions

[nemeosis]

MySQL is good for certain applications, where you only read data, and don't write too much data. This works out especially well for most web sites, since they serve information, but doesn't necessarily allow too much information to be posted by the user.

Lots of message boards on the web use MySQL as their database, because even though people are uploading comments, the amount of data that they upload isn't all that much. Slashdot for example, a popular discussion could prompt 500 messages to be posted in 15 minutes, but still, that's not that much information.

The key word here is transactions, the constant reading/writing, downloading/uploading of information on a massive scale, where each occurence is audited. And I think that's where MySQL has its weakness. PostgreSQL is supposed to be a bit slower, but it takes transactions into account. Red Hat's database software runs on the PostgreSQL engine specifically because of this.

Banking and finance applications require this accountability, because it's just that important. Websites don't need that accountability and overhead, which is why MySQL shines for web servers.

Re:transactions

[Tony-A]

MySQL is good for reading and writing. Just not the same thing at the same time.
MySQL is not good for reading and writing the same table at the same time.
MySQL is lousy at handling writing and slow readers, enough so that I'd put slow readers on a separate slaved system.
If everything serializes nicely in the allotted time, MySQL will perform beautifully. When it doesn't, you get a cliff-edge like thrashing in the old time-sharing systems. When it doesn't, you'll find you need a much bigger and faster system.
About transactions. They are logically required when you have two or more things to update that must both succeed or both fail. The downside of transactions is that your transaction can fail for reasons outside of what you're doing. If you transfer funds from checking to savings at the same time that interest is updated on your savings account, One of the transactions had better fail. Now life gets interesting if the bank cannot update interest payments because customers are messing with their accounts.

Re:"Ethically Obliged"?

[RevAaron]

I don't think the writer was confused in that the GPL is legally binding rather than ethically binding. That is, the GPL only legally requires you to redistribute your code if you pass out/sell the binary, not if you make the changes for your in-house setup. However, if I am a business using a heavily modified version of MySQL, adding tons of great features that make it a real player with real enterprise databases- but not sharing or selling the binary, there is still an ethical obligation- not a legal one, pressure from the community at large to share your changes. You see it all the time in the Linux community in especial.

That is how I read that statement, and from that standpoint, the author is correct.

"rollbacks" are an advanced feature?

[markv242]

I'm sorry, but that's like saying catching exceptions in your JSP code is an advanced feature, and you don't really need to use it.

Commit/rollback is an essential component to any decent data management system. Until you are absolutely sure that your data is correct -- that is to say, until you have done all of your transactions on the page successfully -- you should never actually write data to your database. Without using commit/rollback, you are stuck with the haphazard method of trying to manage potentially disastrous records of data showing up in your db.

Your other quote: "And MySQL will blow the doors off of Oracle and other databases in terms of raw speed" is similarly incorrect: MySQL may be faster when you are dealing with a small amount of connections, but as soon as your application starts getting any amount of concurrent users, MySQL is famous for falling down rather rapidly as it strains to write its data to disk.

MySQL cannot scale reliably, period. Having two database systems act as a pool, under MySQL, is a crapshoot at best. Unless you like designing single points of failure into your web applications, stay away from MySQL.

Simply put, if you expect your web application to get any amount of decent traffic (say 100,000 pageviews+ per day), then MySQL is simply not an option. Oracle is simply the standard upon which others can only attempt to compare themselves to. MySQL may be fine for the low-end "check out my k00l dynamic site!!11!!" crowd, but for professional web applications, MySQL has a long, long ways to go.

Missinfg Features

[juergen]

As long as MySQL doesn't conform to all of ACID, it won't be used by serious players. So all those who use Oracle etc. and need a real RDBMs won't even try to switch. There was a lengthy discussion (or should I say ranting) over this in user comments in the online MySQL manual, but it looks like they removed that. Here's the best link I could find: Manual/ACID.

All those who can live with less, well, IMHO having these features still makes development of sound applications so much easier it pays off having it. PostgreSQL has most of Oracles features, conforms fully to ACID, costs the same or less as MySQL (nothing, compared to MySQL which is virtually useless free without the commercial table handlers), and there are some companies supporting it too.

In my experience an application which does correct error checking and handles faults etc. is not faster in MySQL than in most other DBs, just harder to write. And there are alternatives to PostgreSQL, if you don't like it.

Jürgen Strobel

No. It isn't.

[philovivero]

MySQL is not a threat to the bigwigs, because they compete in different realms. MySQL is a threat to filesystem-storage and BerkeleyDB.

PostgreSQL is a threat to the bigwigs, however.

This is not to say it won't change. MySQL apparently is trying to implement features that would make it compete with real relational databases, but last I heard, views weren't on the list, so I'm not holding my breath.

Other OSS projects that may be a big threat include SAP DB (used to be Adabas D) and... uh... right. There you go. Reply if you're a real DBA and think there's another competitor in the space of true relational RDBMSs. Hint: If you think MySQL could be on the list, you're not thinking of industrial strength databases.

Oracle is preferable to me & my company.

[BoomerSooner]

However we use MySQL, MS SQL Server and Oracle (different solutions/architectures). I don't see the pricing problem with either MS or Oracle. You can get the standard editions for around $1500.

Sometimes paying a little can save lots more in the long run. I personally hate Transact SQL but it's probably because I started on PL/SQL first.

However, that being said I just don't understand some of the stupid ass implementations in TSQL.

MySQL is great because it's small, cheap(free), and very reliable (in my usage). Plus it's got that great JDBC driver that some guy wrote (name?) and the MySQL people hired him (way to go buddy!).

Oracle just seems to have the whole ball of wax. I've never felt I'm trying to program (stored procedures) around a piss poor implementation (like TSQL). So for my (and my companies) money I still say Oracle is the way to go. Plus, I have yet to see the reason to migrate from 8i to 9i.

I'm seriously considering implementing Oracle Financials as well. Show me the MS or MySQL product that can compare to that!

Re:I wonder who mysql steals marketshare from?

[Billly Gates]

Also look here.

This shows how much postgreSQL can really scale.

Not really

[The Man]

mySQL is appropriate for upwards of half of all web applications, and could easily own that half of the market. However, that doesn't mean it constitutes a serious threat to the large proprietary database vendors, because that half of the applications are mostly using one or more of:

• Microsoft Access
• Flat files
• XML files
• Static content
• Client-side scripting
• A large-scale database being drastically underutilized

to perform their various functions. In most cases, those functions would be faster, easier to implement, and simpler to manage using mySQL.

For applications with these types of functions, which do not include complex queries, large transaction volumes, rigorous reliability including transaction log backups, recovery, replay, and replication, mySQL represents a major force. Unfortunately for mySQL and those who would have it take over the world, there's not much money available for those applications. Therefore, expect to see mySQL's installed base continue to increase while its revenue-based market share remains small.

For applications which do require features and levels of reliability and capability not offered by mySQL, postgres is the only serious freely-available contender. Even so, postgres is also somewhat less capable than Oracle or DB/2 and will be confined to the middle tier of applications - those which require better reliability and scalability than mySQL can provide but for which funding is scarce. Postgres probably does represent a serious threat to Microsoft's SQL Server, if only because Postgres is platform-independent and supports platforms which can scale beyond anything Windows can run on. Both are otherwise middle-tier products which are not and will never be taken seriously by the largest and most demanding database users.

Who are those users? Banks, government agencies, stock exchanges, payroll and records processing firms, insurance companies, large multi-site call centers, and other huge-scale enterprises. The top proprietary databases offer capabilities that do not yet exist in the Free Software world. For these users, who are less than 1% of all customers but which represent maybe 80% the revenue in the market, there is no substitute. These customers will stay with their existing solutions - Oracle, IBM, Sybase - until the systems running them give out. Then they'll call that company's professional services department and offer them a few million more to upgrade the system. That's the way it works. The system has to be attacked one customer at a time, an expensive and time-consuming process consisting of many lunches, legal bribes, and unrealistic promises.

I think the answer to whether mySQL is a significant threat to dominate the market economically is pretty obvious. Even if mySQL moves up to the middle tier to compete with Postgres and MSSQL and is installed in every application for which it is suitable, the product would still command less than 10% of the revenue in the market.

What a silly question.

Apples and Oranges

[SatanicPuppy]

I don't know why people insist on comparing MySQL and Oracle. Oracle is huge and bloated, but it runs pretty quick, and is chock full of the sort of features you need if quadruple redundancy and data integrity are a must. If I'm working for a company that can afford the licensing, I'm Oracle all the way...There is no commercial product that really compares.

On the other hand, if I'm dealing with a company that can't toss around the kind of money that you have to have for an Oracle DB, MySQL is my number one choice. I can slap the GUI of my choice on it, take care of data security with a hard backup and pocket a few grand of pure profit that I didn't have to spend on liscensing. You can argue Postgres, but I've never run into a case where I couldn't work around those features that haven't been implemented in MySQL yet.

The one thing I can't stand is when someone suggests: "I can't afford Oracle, so lets' go with a MSSQL database." That's like, I can't afford a space shuttle, and a ferarri isn't good enough for me, so I'm going to buy this million dollar llama instead because 1000 marketing agents can't be wrong, right?"

It has all the same feautres as Oracle, it's just that the features in Oracle WORK.

Just my .0363160 Bulgarian Leva worth

Re:MySQL DOES have sub-selects

[micromoog]

...as the MySQL guy pointed out a log of sub-selects can be done with joins.

This is a pathetic excuse for a MAJOR lack of functionality. If a query can be rewritten to avoid the sub-select, why didn't the MySQL optimizer just do so?

Until a database can support transactions, subselects (yes on UPDATE/INSERTs too) and views (one of the most fundamental relational features) it has no business pitching itself as a real relational DBMS. MySQL is a glorified file system, and works well for people who need a SQL-like interface to a fast file system.

Re:The odd thing about MySQL

[jenkin sear]

In my experience, MySQL has been faster at doing select-type operations. I use it for a web-based CMS, where transactions are unimportant, and the majority of database work is grabbing stuff from the DB and displaying it.

I use postgres when I'm concerned about data integrity, and speeding up writes to the database- if I'm doing a sufficiently complicated write to the DB, postgres' stored procedures make it a much better idea. I've used it for embedded-type monitoring and data collection applications.

So there are situations where one or the other is better- like sometimes perl is better, sometimes C is better. Different tools for different jobs.

Get serious

[tmark]

no mention of PostgreSQL or mSQL,

Is this a joke ? Forget, for a moment, the conclusions we're supposed to draw from 1) the observation that MySQL may run a lot of websites (this is about as relevant as pointing out that Hyundais outsell Ferraris - doesn't mean that Hyundais are superior vehicles), and 2) a lot of commercial websites might run MySQL (also about as relevant as pointing out that companies buy more Ford Focuses for their fleets than Hummers - doesn't mean the Focus is a 'better' vehicle than the Hummer).

mSQL is about as far away from providing the feature set of MySQL as MySQL is from providng the feature set of an Oracle or PostgreSQL - which is to say, worlds away. Sure, MAYBE mSQL is the tool for a particular job - but then we have to ask, are flat files a threat to the mSQLs and MySQLs - hell, the Oracles- of the world ? After all, flat files are free and we know they're in wide use in lots of companies.

Re:If MySQL was just a bit more user-friendly...

[happystink]

I agree 100%, I think a huge amount of MySQL catching on has to do with the online docs which are great. Most people getting into mysql are new to databases, and having all that info super-handy in a great structured format is very very handy, yup. I would have never got into mysql without it either, because for years there were no books on it.

Re:Why not mySQL?

[Hrunting]

The article is 3 years old, yet mySQL still has problems as they developers don't seem to believe that ACID is important. Open ACS on "Why Not mySQL" [openacs.org]

Well, the ACID qualifications have been satisfied by MySQL through the InnoDB handler for over two years. Other issues, such as advanced SQL features, are still in progress.

But to the original point, I think it's a good thing that MySQL doesn't think that ACID is important. They have different priorities. Their priorities do not lie in making a database that conforms to someone (anyone) else's theories of the perfect database. They implement features that are requested by their customers (pay a minimal licensing fee and you suddenly get a much greater voice in the direction MySQL is taking) and their overriding goal is to implement those features as efficiently as possible, so that speed and performance aren't sacrificed for feature bloat. They tend to implement their features along the line of standards, but they also through in numerous "extensions" to that standard that make way for faster processing and quicker development time. That sounds to me like an excellent way to run a software project.

With that said, they have a roadmap for implementation of various features, including subselects, triggers, etc. and they've already explained why one is getting implemented before the other. If you think a really, really important feature is missing, pay them some money and then say, "Hey, this is a really important feature to us and we just gave you $XXXXX."

Re:Have a look at SAP DB before talking about thos

[Aussie]

SAP DB [sapdb.org] is free, open source and GPL. It also has all the best big-guy features. Not many people seem to know about it - it certainly has small mind-share. But it is the real stuff - miles ahead of MySQL.

But for some reason people ignore it. Is it because it is created by a company and not a group ? Or is it that everybody has already chosen their favorite free DB and won't look at others ?

Sure beats me.

Re:I think PostgreSQL is more of a threat

[maraist]

Actually in 7.3 you can finally drop columns, fwiw.

I don't know about MySQL 4, but the biggest problem is that MySQL seemed to emphasise speed over robustness.. Large scale benchmarking in the 3-tree caused corrupted databases. postgres has had a journal for a little bit now (don't know how long though). Plus postgres's version-based rows allows for some really high performance parallel transaction control.

It all comes down to what you are really trying to do.. If you're willing to lose a day's worth of work, and you're not going to have more than a couple dozen simultaneous connections, then MySQL is probably good for you.

Perhaps 4 has allowed MySQL to catch up with Postgres / surpase it, but it's had too murky a history for a lot of businesses who rank data-integrity number 1.

Re:I think PostgreSQL is more of a threat

[leonbrooks]

You can't import from a backup made by a different verion of Postgres.

I can. I have, many times.

The older version I was using was trying to parse the comment marks (---).

The command-line psql segfaults.

These lead me to suspect that your implementation was broken. I've never seen them happen.

not being able to delete a column, or change a column type.

ALTER TABLE [ ONLY ] table [ * ] ALTER [ COLUMN ] column { SET DEFAULT value | DROP DEFAULT }

ALTER TABLE [ ONLY ] table [ * ] RENAME [ COLUMN ] column TO newcolumn

I am always changing a column type to varchar(x) and pruning garbage off it (eg dollar signs and commas) and then converting it back to a numeric (double) field.

Hey, what? You can't store dollar signs and garbage in an integer or float, you shouldn't be trying to feed that to your db in the first place! If you want to do that kind of thing, amidst a `live' table is not the place for it: use a temp table and do it properly. Whis is probably why the PostgreSQL people didn't implement it.

I'd rather wait for MySQL to add the one thing I'm actually waiting for: stored procedures

I hope you've got a lifespan like Methuselah's, then. PostgreSQL does stored procedures in a variety of languages already. Your post does sound like a BASIC programmer grunting and squealing when presented with a real language that insists on him doing stuff like decalring variables, and has scoping etc, forcing him to do `work' (actually investing in manageability) that he didn't have to do before - at least, not up front and in small doses.

Re:I think PostgreSQL is more of a threat

[synx]

it happens, i work for a major company, and due to a wiring error and a mistake made by power techs, major switches and about 20 servers went down, taking out some major production systems.

So no matter what happens, your database will eventually fail and lose power. Even if the power is 100%, the db software and/or OS will crash.

And yes, oracle crashes :-) And hard. But it comes back up cleanly, which is the important part.

Summary of arguments for MySQL

[Ragica]

Having browsed this thread I notice there are certain common arguments frequently employed to defend mysql. But what kind of defense are they?

1. Its good enough for 90% of the web applications out there. However. 90% of the web applications out there are moronic, programmed by people without clues. This is a defense?
2. Similar to above: Most people have no need for the "advanced features" of ACID databases. However, most people actually don't realise what excellent use those tools frequently are, and with mysql they will never have a chance to learn them.
3. People don't always chose software purely on technical merit. One poster actually (apparently defending MySQL) held up microsoft as an example for this. I think this previous "defense" shall by the only comment I will make on this point.
4. Mysql is blazing fast. This has been debunked so many times, it is just tiresome to do so again. I'll merely rephrase another reply in this thread: sure, because it doesn't have to do half the things a real database does to ensure integrity, and functionality. Nearly any database server can be tuned for speed by disabling (or just not using) features, and proper index maintenance. Mysql on the other hand, can't be tuned for the features it is missing.
5. Mysql is easier to use. In my experience as a database hosting provider, pretty much the only reason this seems to be true is because unfortunately the majority of users got their feet wet in mysql first, and their brains apparently became irrevocably corrupted from the experience; they no longer are able to recognise the proper way of doing things even when it is shown them.

   None of the above is new information. Just my personal summary. In short, (ie. in troll) the argument seems to be simply: "Yes, mysql is pathetic, but so are most of us." Great.
   

Features / cost not the issue

[walt-sjc]

MySQL is great for lot's of tasks, but adding subselects and transactions isn't the issue. Postgres has Loads more features than MySQL, yet it isn't really replacing Oracle in the enterprise. Why?

It's the applications support. If you are buying a $5M ERP, CRM or whatever, it's going to support Oracle, and possibly DB2 or MS/SQL. In order to "port" to another DB, it's going to take a Huge effort with vendor support.

When third party commercial developers start supporting open source DB's, THEN you will see enterprise adoption. In order for commercial developers to start supporting OS DB's, they need to see enterprise demand. Before you will see enterprises requesting MySQL support, MySQL needs to have the feature set needed to support those applications (such as triggers, stored proceedures, etc.) and enterprise level support for clustering, load balancing, replication, etc. MySQL is beginning to get some of these features, but it's not NEARLY at the same level as Oracle.

It's the same situation as it is with operating systems. If the applications you need for your business are only available for the Windows platform, what real choice do you have?

Re:I think PostgreSQL is more of a threat

[Lumpy]

Everytime the server looses power, I have to ssh into client's servers and tell them how much data they've lost (repair table). It's not a happy time, and buy a UPS is not reassuring (most have them, accidentally bumping power switches/knocking cables loose still happens).


this is not the fault of the DB this is the fault of the data-owners.

Obviousally your clients have very little value to their data as they do not have the proper equipment to protect it. Power switches getting bumped? what are they running on someone's old dell desktop in a closet? Buy a Compaq ML530 or other real server instead of running on junk. I have to hold in the power switch for 10 seconds before it starts a shutdown because of the configuration I have. a full power crash means unlocking the back of the server rack and unplugging the 3 power cords from the power supplies. As for UPS, I have a APC1400 rack mount for each server and the batteries are replaced YEARLY as well as the UPS's tested weekly.

we value our data, and it costs us $10,000.00 for every day of lost data. so spending money to protect that data is important to us.

Obviousally your clients do not have a high cost or high value to their data or they really dont care much about data loss, otherwise they would invest in server class hardware and other assurances. I can only imagine the nightmare that is their backup solution if they have such low quality IT equipment in place that your stated problems actually affect them.