Why MySQL Grew So Fast

jpkunst writes "Andy Oram, who attended the MySQL Users Conference which was held April 16-18 in Orlando, Florida, attempts to explain MySQL's popularity in his weblog at oreillynet.com. (More weblogs about the 2004 MySQL Users Conference can be found at the The 2004 MySQL User's Conference & Expo Blog Collection.)"

Comments

Re:It's too bad

[ciroknight]

Too bad indeed.. if it weren't for poor products that get widely adopted fast, graet products would never be adopted. For instance, the reason why the world wide web took off was because Microsoft created a HORRIFIC web browser, but since now all computers had a web broswer, everyone had access.

MySQL was in it's own, a huge part of the dot com boom, and therefore a huge part of the history, and therefore, the future, of the internet. Hate it, love it, it's a great product with a great niche, and for now, it'll continue along that path.

Re:It's too bad

[Anonymous Coward]

Better yet, what would you recommend?

Oracle, of course.

Love,

Larry Ellison

Why MySQL Grew So Fast?

[Anonymous Coward]

Because PostgreSQL takes longer to type :-)

Picking the right tool for the job

[Anonymous Coward]

Slashdot users complain that MySQL doesn't have the full feature set of some RDBMSes... but they miss the point. The reason MySQL has been succesfull precisely because it's been very good at delivering the features that a particular set of people need. To these users, additional features are a liability, not a feature.

This reminds me a lot of DBase III. (Bear with me here...)
DBase III wasn't a very good database program, but in its heyday millions of people used it and it got the job done for them. Even relatively inexperienced users could make use of it and write simple programs to manipulated their data. Even though it sucked, it was the right tool for a lot of jobs at the time.

Compared to DBase III, both MySQL and PostgreSQL are excellent. I wish I'd had either one a decade ago when I started work doing clipper programming for a dog track related publishing company.

For the dog track application I would have preferred Postgres; the rollback support would be pretty compelling for an application like the one we were doing. Rosebud is a sled, and Verbal is a huge liar. Darth Vader is Luke's father, and the Sixth Sense guy is actually dead. The planet of the apes is Earth, and Rocky loses. For something where I was just kicking around a database (Which I've also done a lot of) MySQL would be perfect. MySQL would be ideal in something like the RHS Orchid Registry, for instance.

If application bigotry keeps you from choosing the right tool for a job, you will be a less valuable resource to those who employ you. Not too many people seem to "Get" this. People are often surprised that I will, on occasion, suggest that Microsoft products are the best tool for what they're trying to do. Usually those people asked me expecting a "Windows sucks use Linux" spiel, but if I think their situation warrants it (Inexperienced user, just wants to browse the web, word process and send E-Mail or wants to play games at all) I'll tell them to use Windows.

Re:Picking the right tool for the job

[Anonymous Coward]

The issue isn't really the lack of the feature set, but the fact that the MySQL devs used to be clueless idiots about it. Here's what the docs used to say about foreign keys:

5.4.5.1 Reasons NOT to Use Foreign Keys constraints

There are so many problems with foreign key constraints that we don't know where to start:

Foreign key constraints make life very complicated, because the foreign key definitions must be stored in a database and implementing them would destroy the whole ``nice approach'' of using files that can be moved, copied, and removed.

The speed impact is terrible for INSERT and UPDATE statements, and in this case almost all FOREIGN KEY constraint checks are useless because you usually insert records in the right tables in the right order, anyway.

There is also a need to hold locks on many more tables when updating one table, because the side effects can cascade through the entire database. It's MUCH faster to delete records from one table first and subsequently delete them from the other tables.

You can no longer restore a table by doing a full delete from the table and then restoring all records (from a new source or from a backup).

If you use foreign key constraints you can't dump and restore tables unless you do so in a very specific order.

It's very easy to do ``allowed'' circular definitions that make the tables impossible to re-create each table with a single create statement, even if the definition works and is usable.

It's very easy to overlook FOREIGN KEY ... ON DELETE rules when one codes an application. It's not unusual that one loses a lot of important information just because a wrong or misused ON DELETE rule.

The only nice aspect of FOREIGN KEY is that it gives ODBC and some other client programs the ability to see how a table is connected and to use this to show connection diagrams and to help in building applications.

At this point anyone with RDBMS experience is rolling on the floor. THAT is why MySQL gets no respect.

I strongly disagree

[Trevor Goodchild]

Mr. Oram's long-winded screed on MySql, while interesting, really makes the situation sound much more complicated than it is. You don't need to over-analyze this thing. The truth is simple and readily clear to everybody already.

In a nutshell, MySql is free. Is it great? Hell no, but it's free. The only deep understanding of human nature or the DB marketplace one needs to comprehend here is that given the choice between something great and expensive vs. something mediocre and free, the overwhelming majority will go for free.

MySql has always had huge problems preventing it from being accepted in the real "enterprise" marketplace, but most of us aren't in that market. Most of us need to yank a bit of data and cram it into a web page moderately quickly and as cheaply as possible. MySql does this quite well.

What doesn't MySql do well? For starters, it's much slower than Oracle, MS-Sql, and even Foxpro. It has no row locking, no transaction support, and minimal cross-platform compatibility. But, it's free and it works more or less ok on Linux.

Perhaps the real truth that Oracle fears is that eventually DBAs will come to realize that 99.9% of their storage needs aren't so "mission critical" as they would like to believe. I mean really, how many people out there can truely justify the cost of a full featured, robust database like MS-Sql? 10%? 5%?

For the rest of us, a free - albeit slightly dodgy - solution will work fine.

Re:I strongly disagree

[Daniel Dvorkin]

What doesn't MySql do well? For starters, it's much slower than Oracle, MS-Sql, and even Foxpro.

I've never used MS SQL Server or Foxpro. But having very recently developed a project on two DBMS tracks (Oracle and MySQL) I can tell you that identical queries on identical schemata with identical data are provably faster with MySQL than with Oracle.

It has no row locking, no transaction support,

This is no longer true.

minimal cross-platform compatibility

Huh? I've successfully migrated several complex databases, and the associated applications, between MySQL servers on Linux, Windows, BSD, and Mac OS X with no problem. And I mean no problem; in most of these cases, I haven't had to make a single change to the architecture, data, or application code. Everything just works.

If you want to criticize MySQL, there are plenty of legitimate grounds to do so. (E.g., the lack of support for views, which in my primary job as a MySQL DBA drives me nuts at least once a week.) Don't just make stuff up.

Re:I strongly disagree

[mcrbids]

I mean really, how many people out there can truely justify the cost of a full featured, robust database like MS-Sql? 10%? 5%?

How about 100%!?!? Ever hear of PostgreSQL?

ACID compliance, features that compare very nicely against MS-SQL/Oracle, foreign keys, triggers, transactions, embedded function definitions, the whole shebang.

About the only thing that it lacks (for free) is decent clustering/replication capability - and you can buy that fairly easily in the form of patches.

I've been using it for years, and it's a joy to work with!

Re:I strongly disagree

[Osty]

It has no row locking, no transaction support, and minimal cross-platform compatibility. But, it's free and it works more or less ok on Linux

Before all of the MySQL zealots jump all over you, I should point out that MySQL does have transaction support (with the proper table type, and so long as it's built in, and you're using a current enough version, and you made sure to tag your tables with the right syntax to make sure they are of the right table type, etc), and does cross-platform well enough (better than PostgreSQL, as much as I love that engine). I don't know about row-level locking, but I'm sure it can't be far now.

The biggest problem with MySQL is inconsistencies in both the engine itself and the development community. For years, the MySQL community told developers, "You don't need [transactions | foreign keys | triggers | stored procedures | subselects | ...]! You can work around those limitations in your application code and be better off for it!" Only they then go and implement those features that developers "don't need". That would be fine, except that the implementation of the features often leaves something to be desired, and have too many quirks. For instance, I mentioned above that you can only get transactions and referential integrity if you're using the correct table type. However, that table type is not the default, and even if you do create your tables properly to take advantage of those features, MySQL doesn't fail if the table type is not supported, choosing instead to make your table an inferior type. Now you think you have transactional support and referential integrity because your database built just fine, but what you don't know is that your hosting provider didn't build that table type into their deployment of MySQL, and you really don't have those features at all. Good luck trying to figure out why your data is corrupted even though you had proper transactioning in your code.

MySQL has other problems as well. For example, if I want a column to be NOT NULL, I want any code that tries to insert a NULL into that column to fail. I don't want the engine to try to pick some default value for me. If I wanted a default, I would've added a default. That's why default constraints exist. By that same token, if I want a column to allow NULLs, I want to be able to put a NULL in the column. I don't want the current date/time instead of a NULL. If I define a column as auto-incrementing, I want to get an error if I try to insert something into that column. I don't want it to quietly succeed.

There's plenty more on that page, though most MySQL apologists will tell you either that the problem is fixed (which is fine, except that being fixed in the latest beta is far different from being fixed in the most widely-deployed versions from different hosting providers and such), or that it "will be in the next release". These are the same people that will tell you that stored procedures are unecessary, and anybody that thinks they are is stupid (or they'll tell you that the performance gains from being able to compile your SQL code is negligible, while completely ignoring all of the other benefits of stored procedures ... *COUGH*security*COUGH* ...). And so on. MySQL is fine for what it does, but it's not the end-all of SQL software. Far from it.

Re:I strongly disagree

[Osty]

Pushing the data integrity code to the app instead of asking the RDBMS to do all the heavy lifting will come to bite you in the arse when scalability becomes important.

Hell, I don't even care about scalability. How about simply being able to trust your data? I'm currently working on a database-backed project that has aboslutely no foreign key constraints at all (among other problems, though the SQL engine is not MySQL and we are slowly but surely fixing the issues). We're constantly trying to clean up our data sets (not fun when you're talking about several tens of millions of rows) and track down the offending code so we can add constraints and then handle the insert errors properly, but it's been a long and arduous process. We're actually at the point where we're willing to throw away the current system and start over (or, well, run side-by-side for a while). It's not fun.

If MySQL works for the majority of installations, so be it. You never get to be number one in your pack by following the pack. You have to innovate and do what you do really well. "Good enough" only gets you outsourced.

Very true. Let me also add for those who think that MySQL is a good learning tool -- it's not. While MySQL does support much of the ANSI standard, you're going to run into problems (some of which are MySQL's fault, some aren't):

• The tricks and hacks you have to do to work around MySQL's limitations (subselects, views, stored procedures, triggers, etc) are unnecessary in a real RDBMS, but you won't know that because you only know MySQL.
• More importantly, the hoops you have to jump through in MySQL often lead to suboptimal SQL code. You may not really notice this on the light data sets where MySQL excels, but you will as soon as you try to migrate this knowledge to a larger system.
• MySQL gives you a false sense of performance. Your data sets are small (ideally, otherwise you're going to be in for some shit with MySQL), and so you don't care about proper indexing, whether you're doing index seeks versus table scans, whether your data is well-normalized versus normalization trade-offs for performance, etc. What performance tuning you do learn from MySQL likely won't translate well to other systems.
• MySQL has its own non-ANSI syntax additions that don't apply to other RDBMSs (AUTO_INCREMENT column type, for example)
• Similarly, other RDBMSs have their own set of specific keywords, so you still have to put in the time to learn them (do you know how to do an auto-incrementing column in SQL Server? MySQL won't teach you that)

If you want to learn, get yourself a real RDBMS. Microsoft's desktop engine version of SQL Server is free, and Oracle has free downloads available as well. If you don't qualify for either of those or don't agree with the licensing, at least use something more robust like PostgreSQL. If you're trying to learn, you'll be much better off learning on any of those platforms than you will with MySQL.

Re:I strongly disagree

[GooberToo]

200,000 rows is still considered to be a small database. If you access this database with anything concurrent select/insert/update activity, you might consider looking into PostgreSQL.

While obviously, PostgreSQL isn't a cure all bullet, you might be surprised as how well it performs and how much better it scales.

Re:I strongly disagree

[Anthony Boyd]

With Oracle, watch the queries perform the same under a far greater load than MySQL will handle.

I call bullshit. In e-Week's tests, Oracle and MySQL were dead even under load.

Re:I strongly disagree

[GooberToo]

Please.

Okay, since you insist.

Postgres is the only database in wide use which is not multithreaded.

So? And your point is?

Don't make up lame excuses as to why it's better then multi threaded databases.

Ah. Thankfully, I didn't have to make anything up. It's a simple fact. That means it's true to the layman reading this. ;) In threaded applications, simple stack or data segment corruption is all that is needed to corrupt anything from a single field, all the way up to a page, and perhaps more. This doesn't mean that threading shouldn't be used. It does, however, mean that simply stating that PostgreSQL uses a process model and try to imply that it's bad, is completely false. Especially in light of the fact that electing to use a threaded model carries significantly higher risks. Worse, should a single thread become corrupted, it corrupts the whole process. That means, even if the moment the corruption occurs, no damage is done, the potential for damage is still lurking as it may still be lurking within the process it self. This also means that should the process fail, the entire database is down, having crashed more than likely. This also means that the likely hood for repeated corruption is also increased.

A process model, on the other hand, means that, at worst, a single connection (a single backend) will fail, allowing all other backends to continue. This, in theory, means a larger window for larger uptimes. Best of all, in the event that process corruption occurs, and the connection is transient, the potential for damage ends when the client disconnects. So, this leaves us with pretty much just shared memory being open to corruption. While it's possible this could go unnoticed, the odds are significantly lower that the corruption will go undetected before it has a chance to be written to disk, because of the data layout in shared memory and the implementation of checksums of hashes.

In other words, the simple fact is, aside from the process fork versus thread spawn overhead, a process model is easily argued to be a superior model. So really, what you hoped to be a plus is litterally a negative in the eyes of all that understand how these things are put together.

Because they were the first to support subqueries

[rimu guy]

Not.

MySQL has always been fast. That is probably why most people use it.

MySQL has also been easy to manage (e.g. move database files from one subdirectory to another and the tables have also moved). That kind of simplicity brings tears to the eyes of an Oracle admin. There are a few options you can tune and teak, but by and large it just works out of the box (er, RPMs).

And of course the reason it has been so popular is that it has been so popular. If you get my circular drift. People use it because there is a lot of documentation about it. Perl and PHP pretty much always have the MySQL libraries so it can be used on web sites, etc.

Speacking of those subqueries, what's up with the delay getting 4.1 out from alpha to beta/gamma/production. I want to start using it. And 4.1 has been out in alpha for over a year now. Not to mention new development is already proceeding with the 5.0 release.

- Run the latest and greatest alpha MySQL database on your own VPS

I like MySQL

[Anonymous Coward]

Not everyone is a database elitist. Not everyone has to worry about transactions nor store procedures. Triggers are neat, but not always necessary. (Insert obligatory VHS/Beta comment here.)

What is great about MySQL is that it gives the average Joe or Ho with a machine a chance to build a database backed application of some sorts. Its cool. Its free. Its fun.

Now for all of those who have based their fragile nerd self esteem on their DB experience or knowledge need to turn off their computers and go down to the local bar and talk to the local people about local people's reality. Ya MySQL is not DB2 nor Oracle, but it is still pretty cool. And the fact that Monty has written the greater portion of it is pretty cool too.

Naysayers need to get laid!

Re:Pretty simple.

[DAldredge]

3: MySQL SILENTLY ignores portions of the SQL spec and doesn't inform the applicaion that it doesn't do what the apps need it to.

Re:Pretty simple.

[mabu]

4. A tight, clean system that isn't bloated with crap that is superfluous to its main objective.

5. A package that doesn't morph into a different product every six months with a new, catchy name, or divided into umpteen modules scientifically designed to require you to get every possible option in order to finish your application.

6. A software package that isn't so ridiculously complicated to install and use that companies make more money selling training and support than they do implementing applications.

I still prefer PostgreSQL

[Vellmont]

MySQL still doesn't support triggers, and I like advantages of having support for varchars larger than 255 characters. Postgresql also supports the more standard method of an auto-number unique ID field of the sequence (and argueably more flexible). I _really_ like the flexibility of authentication that postgresql offers, though I haven't looked at MySQLs authentication as exensively.

MySQL has grown up a lot though. Given how primitive and featureless it used to be it's gotten much better where the differences between the two have become smaller.

MySQL got there first and was "good enough"

[kcbrown]

MySQL is an interesting example of how you can be wildly successful if you're at the right place at the right time with a product that's just good enough for the mission people have in mind.

MySQL, even now, is actually rather sparse as database engines go: it lacks stored procedures, triggers, constraints, etc., in short many of the things that a serious DBA considers necessary in a database engine.

But the mission it was originally created for is a mission that's a very common one: a simple, network-enabled data store with a SQL interface. That it lacked transactional capabilities didn't really matter: it was good enough for what many people needed.

So its popularity exploded. In the free software world, there weren't any other contenders at the time that were sufficiently reliable or fast to do the job. PostgreSQL back then just wasn't fast enough, and tended to eat data. Not that MySQL was perfect in that regard, mind you, but at least MySQL gave you the tools to recover your data quickly in the event of a hiccup. PostgreSQL didn't -- it required you to do a full restore from backups, whereas MySQL let you use 'isamchk' to get you up and running quickly. That made a big difference to a lot of people.

Today the story is very different. PostgreSQL is at least as fast, if not faster, than MySQL in many situations, especially under load, and has essentially all the features needed to make it a "real" database: transactions, stored procedures, triggers, views, constraints, etc. About all it lacks now is built-in replication (there exist third-party solutions), nested transactions, and point-in-time recovery (a.k.a. archive logs), things which MySQL is not likely to get anytime soon.

Nevertheless, despite the fact that PostgreSQL is very much a superior solution in just about every respect, MySQL is more popular and thus has better third-party support. And it's thanks to the fact that it was in the right place, at the right time, with a "good enough" feature set.

Re:Because they were the first to support subqueri

[Anonymous Coward]

The statement "move database files from one subdirectory to another and the tables have also moved" is a tautology. The tables are in the files, so of course they move.

"That kind of simplicity brings tears to the eyes of an Oracle admin." No, it doesn't. I'm an Oracle DBA, and I'm not crying because MySQL lets you move datafiles - so does Oracle. Typing "alter database rename datafile..." isn't exactly rocket science.

Oracle also works "out of the box", especially when it's used for the sort of applications that can make do with MySQL. Granted, big motherfucker DBs might need some basic memory tweaking, but small sites can generally get by with the default parameters.

MySQL is popular because it's free, and it meets the needs of certain users. That's all there is to it. It isn't better, and it isn't worse.

Re:Why?

[Vellmont]

I think Access is great, for what it's intended for. It's perfect for small databases where someone would otherwise use flat files. It's also a great reporting tool to use to connect to other databases via ODBC.

The problems with Access is just that people often don't know what they're doing and create awfull legacy systems that they then expect to keep extending. That's a problem that lies between the keyboard and chair, not with Access.

If you want a database to complain about, complain about FileMaker Pro. It's an ugly, non-relational database that seems to ecourage people to make terrible, ugly systems.

I've Tried PostgreSQL

[jwbrown77]

I understand it's supposed to be better because it supports more ACID compliant features (and has for a long enough time to consider them stable). I just can't seem to get the hang of PG though. I far prefer the mysql command utility (and mysqladmin) over psql, I just find it easier to use. I also don't like the way PG handles users. I find it easier to add and modify users in MySQL and set their privileges with it's table method than PG which is more configuration based. I could figure everything out, but I've been too swamped lately to learn the in's and out's of PG. That's why I continue to use MySQL, because it fits my needs. Not PG's fault, but it's one of several reasons people still use MySQL.

bullshit

[ErichTheWebGuy]

Remember when Reasoning, Inc audited the code? They found that it had 0.09 errors per 1,000 lines of code while proprietary competitors had 0.56 errors per 1,000 lines. That's more than 6 times as many errors in the proprietary databases. http://searchenterpriselinux.techtarget.com/origin alContent/0,289142,sid39_gci941817,00.html

Quality product. That is why it is popular. Perhaps you should research your argument before posting a flame next time.

MySQL, PostgreSQL, Oracle, MSSQL, etc....

[linuxtelephony]

Over the years I have been a user on PostgreSQL, MySQL, Oracle, and MSSQL, and an admin on PostgreSQL and MySQL.

Having said that, I prefer MySQL and PostgreSQL to both Oracle and MSSQL, in most situations. However, given my experience with MySQL and PostgreSQL, I am glad that I have returned to PostgreSQL.

Why PostgreSQL? Simple. I am able to use referential integrity, triggers, and foreign keys in my databases. I can use subqueries, and more. There are certain databases where the data integrity is the important part. Having the database enforce that integrity is cheap insurance. Having transaction support, including rollbacks, are great for operations that affect multiple tables. I also like the way Postgres strives for SQL compliance.

MySQL is improving. Everytime I check they are getting more and more support of things I consider critical. Especially in the last 9 months to a year. But not yet enough for me.

I was involved in a fairly large scale production system that used MySQL as its heart. Unfortunately, at the time, PostgreSQL just did not have the performance that was needed. And, the main DBA was a mysql zealot. With MySQL, we seemed to constantly have to figure out creative work arounds for what MySQL lacked. Table level locking was a headache. No referential integrity and lack of transactions were a nightmare.

I still see MySQL as the better solution when you need to serve text files via SQL really really fast. But, when you need to provide a specific level of accountability and traceability, PostgreSQL is still my choice.

Views? Subqueries? Easy to move databases?

[linuxhansl]

I for one cannot understand how anybody can do *any* serious database work without views and subqueries (the latest MySQL alphas/betas have support for subqueries). The whole relational theory is (almost) broken without these.
To me that's mindboggling. Without that I'd rather use berkeley DB or flat files to load and store my data. How do you do row-level security without views, what about column security. Or just different views for different users. These are just a few example that require *a lot* of coding without database support (not to speak about performance). Heck, do people even understand what views (or triggers, etc) are?

People say it's easy to move databases around my MySQL. Yeah, sure, as long as you stay with the ISAM tables, which do not support ACID. InnoDB tables support ACID but cannot simply be copied around.

It makes me shudder to think about all the future DBAs that accept the low standards MySQL is setting.

Re:Pretty simple.

[kpharmer]

> 3. A very clean and easy to use API, in a language that is universally understood and almost universally portable (C) for incorporation into other products
> such as PHP, Perl, Python, Apache itself, and an endless amount of other applications.

Portable - only in the context of its ability to compile & link. Not very portable in the sense that its users require it.

MySQL has a nearly complete disregard for ANSI SQL standards - which results in the least portable syntax of any relational database I've used. This list includes:
* mysql
* postgresql
* oracle
* informix
* db2
* sql server
* sybase

Additionally, since it's the only entry on the above list that is missing or has limited support for transactions (yes I know - you can get it with its slower innodb file system now), views, etc - much of the sql written is brain-dead compared to other databases. So, one query in oracle/postgresql/etc can easily turn in three in mysql. This mapping queries between mysql and other databases causes considerable performance problems - since most other databases provide the best performance (in most cases) with given a single query to perform a unit of work.

So, if the non-ansi syntax isn't a big enough pain-in-the-butt, having to rewrite the queries and application to get reasonable performance often is. Amazingly, I've found that it's easier to convert an application from SQL Server to Oracle than from MySQL to Oracle.

Ah well. I suppose much of this will improve over time as they rewrite their engine to include more and more of that functionality that nobody wants.

But in all seriousness - there's not much to analyze about its popularity guys. It pretty much boils down to:
right place at the right time
It owned the light, easy and free niche four years ago. It's a different ballgame with postgresql now, but mysql has built up quite the following in the meanwhile.

I dislike MySQL

[Osty]

Not everyone is a database elitist. Not everyone has to worry about transactions nor store procedures. Triggers are neat, but not always necessary. (Insert obligatory VHS/Beta comment here.)

You're right, not everybody has to worry about those issues, but maybe they should. However, the problem is not so much with MySQL itself (it's a good, fast, lightweight storage system for simple and small amounts of data). It's with the perception that MySQL is every bit as good as a more robust engine (Oracle, MSSQL, DB2, take your pick) for any application. That is definitely not the case. As well, knowing MySQL does not make you uniquely qualified to decide that it's better than one of the other choices for a system that needs that level of robustness. The biggest problem is that people who only know MySQL choose MySQL because that's all they know, even when it's completely unsuited to the task.

Add to that the arrogance of the MySQL developers ("These aren't the stored procedures you're looking for ..."), and the zealotry of the user base, and it's easy to see why those of us who do know a thing or two are bitter about MySQL. I laugh anytime someone tells me that they can enforce data integrity from their application layer instead of using foreign keys (usually while trying to clean up their mess of a data set so the data itself can be trusted). I find it hysterical when I'm told that stored procedures are a complete waste of time (typically while fixing someone else's SQL injection problems because they insisted on writing dynamic SQL queries from their code).

I'm all for making databases and db technology more available to the Average Joe, but MySQL is not the way to do it. If you need free, there are many better alternatives to MySQL (especially if you only need free for training purposes, because then the big three are available to you as well).

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Pretty simple.

[Chexum]

Interestingly, nowadays no one seems to remember that in '97-'98, there were basically three usable databases: Postgres95: sometimes difficult to compile and set up; mSql from Australia, which was popular, but was for non-commercial use only (thus they excluded themselves from many "markets"), and mysql, which at the time looked like a buggy clone of msql, but free to use.

Most of the people at that time usually heard about apache + msql, and then stormed over to apache + mysql. Me, I managed to get Postgres95 to work, and never longed for anything else :)

mSql, aka minisql tried to make a comeback lately, but I they botched their opportunity years ago with this "non-commercial use" stuff.

Why MySQL grew so fast:

[DrMrLordX]

1. Bovine growth hormones in its milk
2. Possible steroid abuse

Re:Yeah... I'm gonna sqitch from Oracle to MySQL

[ErikZ]

"Whatever moron made that decision needs to be outsourced to India. Thats sort of like trading in a shiny BMW for a freakin go-cart."

I can easily think of a reason to go from Oracle to MySQL.

1. You don't have a database that needs Oracle.

2. Therefore downgrading will save you fat sacks of cash.

I've known someone who was fired for choosing Oracle. They suck an enormous amount of money into the project and it was far more database than they needed.

Right On

[Caiwyn]

The article rambles a bit, but it does hit the nail on the head when it comes to what drove the rapid increase in popularity of MySQL -- that it was small, fast, and easy to learn, mainly due to the fact that it did not include features that were, for many users, extraneous.

When I first went looking for a database to drive my website, my more knowledgeable friends and professional acquaintences all hawked postgresql. Since it was the default db that shipped with Red Hat, I figured I'd try it. I liked how robust it was, but I had a hell of a time finding support for it in the applications I wanted to run. I eventually switched to MySQL (which I had already used for various other projects) because it still remains easier to use, and because PostgreSQL is way more than I need.

The simple fact of the matter is that most users don't need ACID compliance, or transactions, or what have you. They need a storage system with sql interface, and that's it. Users who need more from a database would pass up MySQL for something better suited to their needs... but those users are in the minority. Everyone else's needs are simple -- MySQL sacrificed the less essential features for speed, simplicity, and ease of use. As a result, it was more attractive to people who were adequately served by its feature set.

And as MySQL has progressed, it has added in many of those features that higher-level databases like PostgreSQL offer, allowing us the option of using those features in the future.

The dual license is, in my view, a great business model. It provides the revenue stream open source projects need without sacrificing the freedom for those users who embrace the open source concept. As I understand it, it's free for use, and free to distribute under the terms of the GPL... but you have to pay if you want to use it in a non-GPL product. To me that's genius -- it forces a licensee to play by the same rules he sets, which seems only fair. I wouldn't be surprised to see more projects adopting similar models, nor would I mind.

Re:Pretty simple.

[Eric Savage]

A tuned query set is pretty much unportable no matter what DBMS you are using. Once you start getting into maintenance tasks, vendor-specific performance boosting options (which are often the reason you've chosen a vendor), and basically anything beyound the most basic selects and inserts, you code becomes tied down to a server. Also the general disregard most servers have for ANSI means that it is only a standard in theory, not in practice.