"More recently, my own conversations with EnterpriseDB sales executives indicate an acceleration of commercial interest in Postgres, including from MySQL customers who are anxious that Oracle may ruin MySQL for them."
The silver lining. Hopefully, this will mean that more projects will target Postgres as a primary deployment platform.
It is a little sad to rewind the tape and go back to 1999, when both MySql and PostGres were talked about as being roughly equal. MySql had not yet taken over open source databases yet. MySql was greatly helped by the rise of PHP - I think those 2 technologies grew up together, and leaned on each other. But I also recall, when I was learning PHP in 1999, most PHP books devoted some time to Postgres. And PHP supported Postgres from the beginning. It wasn't till a few years later that I started to see book titles like "PHP/MySql development for beginners" as if those 2 technologies just naturally belonged together.
I recall when Tim Perdue published this article in 2000, and the strong impression it made on me that PostGres was the much better database:
"The most interesting thing about my test results was to see how much of a load Postgres could withstand before giving any errors. In fact, Postgres seemed to scale 3 times higher than MySQL before giving any errors at all. MySQL begins collapsing at about 40-50 concurrent connections, whereas Postgres handily scaled to 120 before balking. My guess is, that Postgres could have gone far past 120 connections with enough memory and CPU."
At that time, circa 2000, developers often claimed that they could live without ACID reliability, in exchange for speed. Thus, there preference was for MySql. There is something to that argument of course. In recent years, the NoSql movement has gone much further, throwing out integrity as a concern, in exchange for massive scaling and fast speed.
Somehow, lost in the shuffle was the fact Postgres is, in most ways, technologically superior to MySql. It may not be as fast as MySql, in some situations, but for a wide range of purposes, it should be really be preferred to MySql. And I think, somehow, developers have often forgotten that, for a wide range of purposes, the best choice would be Postgres.
Back in 1997, my decision between postgres and MySQL was made for me by the fact that Postgres was pretty much impossible to install on my Windows box, while MySQL had a sexy InstallShield.
When you are trying to make your technology attractive to a broad base, it's important to remember that newbie developers will always take the simplest path, and that 95% of all computers are Windows boxes. If your software is not very, very Windows-friendly, you will lose first-timers to technologies that are. This was also one of the big, big factors in PHP's success.
Obviously, running a website or a database on Windows is a bad idea, but you need to learn how to code before you need to learn that fact.
> It came down to one thing: the perception that MySQL was fast and Postgres was slow.
I've always said that Mysql (with MyISAM rather than InnoDB, to be fair) was like a bicycle without brakes. Yes, it's faster going down hills, however...
but that was, I think, what those who criticized MySQL missed. 95% of the use I saw MySQL being put to in the late 90s and early 00s would today be done in some distributed key/value store. Most people using MySQL didn't care that it wasn't a very good RDBMS because they didn't need a very good RDBMS. they needed a fast key/value store that could handle basic locking most of the time, and that worked out of box without a lot of setup.
Markets weight features. Sometimes performance is most important, sometimes scalability, adoptability, usability, reliability, cost etc. It can even change over time.
This is self-evident, but it's so easy to forget when one is familiar with the overall comparative technical merits - this one is so much better in most ways. How could the other one win?!
The assumption is that those are mutually exclusive.
I've been watching PostgreSQL development back in the days and to me it's clear that the biggest mistake PostgreSQL made was not responding to market demands as quickly as MySQL did.
Windows support, built-in replication, built-in full-text search - those are all things that MySQL added much sooner than PostgreSQL. Those are also the features that people cared about and a big part why they were choosing MySQL over psql. At some point early lead turned into crushing defeat in terms of market and mind share.
You can claim that some other features constitute "best free rdbms" but clearly PostgreSQL team does think that those are included in that definition since eventually they added all of them. The problem is that they did it long after MySQL had them. Too little, too late.
The sad part is that it wasn't always a matter of coding but a matter of bad priorities and bad marketing (where I include defining what the product is and isn't as a fundamental part of marketing).
For example, I believe psql had high-quality full-text search coded before MySQL did but the core team resisted shipping it by default. Instead for a long time a super valuable feature was part of "contrib" package i.e. you had to jump through hoops (like compiling it yourself) to get it to work.
The main reason why PostgreSQL failed to MySQL was that the project was driven by extremely bright coders but terrible marketers.
Remember that PostgreSQL isn't run by a commercial enterprise, it's written by volunteers who as a general group couldn't care less about marketing, market share or what your business wants.
For an rather more extreme example of this see OpenBSD, who basically say "if you want to use it go right ahead, but we build OpenBSD for our own use, not for your use."
> and that 95% of all computers are Windows boxes.
According to reddit statistics, this is no longer the case (68% only). And back in 2000, I knew almost nobody in the web dev business using windows, but Macs instead.
>back in 2000, I knew almost nobody in the web dev business using windows, but Macs instead.
Either you had a very eclectic group of friends, or your memory is slipping a bit.
The big in-rush of web developers to the Mac platform did not take place until Macs became Unix machines. Back in 2000, there was no such thing as OS X, unless you count the public beta. 10.0 suffered from abysmal adoption. I don't know any developers who used Puma, much less Cheetah. Most of us were using various Linux distros. However, by somewhere around 2003ish, with Jaguar, the switch had begun in earnest, but Mac's didn't predominate among web developers for a while longer.
At that time it was also considerably more expensive to get servers, so hardware scaling of any kind was less desirable. The cheap virtualization we enjoy now only came in around mid-decade.
My personal view is that part of it was the unintentional sabotaging of SEO - MySQL is only spelled one way, while there is Postgres, PostgreSQL, pgsql (as used on some mailing lists) for Postgres. This fractured search results and made it tougher to find information vs. MySQL.
The letter in the article reminds me of an engagement I had during the dot.com boom. Oracle told my client they had to buy their license right away before some imminent price hikes, so they did. The next week, Oracle dropped their price by 100K for my client's equivalent licensing level. Needless to say, I had one --pissed-- customer on my hands.
One of my corporate clients needed to choose between either MSSQL or Oracle for an in-house system, and this sort of garbage is exactly why I pushed them hard towards MSSQL. I'm not a fan of Microsoft's licensing schemes in general, but they look positively saintly compared to Oracle.
I had a look at Oracle prices the other day just out of curiosity. Back in the day driver support used to be solid for Oracle and touchy for everything else I used so that's the context in which I know it.
I went to the store, then clicked oracle database, and found myself looking at licenses of Oracle database Enterprise for just six hundred pounds. That's a lot cheaper than I remember it being. I added to cart to see what would happen. When you do this, it adds a "first year support" line as well that's not quoted on the page but does contribute to your bottom line. I found that deceptive.
Then I had an idea about what might be going on. I dug further to find the yearly cost of support for the database. It's far more expensive, and back to the prices of the old days. So I assume that you buy it at a merely expensive price, and then if you want fixes to their bugs, you'll have to keep paying money for it at a higher rate on a per-year basis.
Digging further, I found a link for Oracle database standard edition that was far more expensive and quoted on a per-processor basis. £11,730.00 per processor. Ouch.
No joke: When it comes to enterprise software licensing and pricing, a lot of the time I find that even the vendor's salespeople don't know how it works.
I think MySQL needs to follow the path of Libre Office (the document foundation) and fork. The project should be run by the community and not controlled by Oracle. Oracle, like Sun did not create the database (Sun bought it in 2008) and are trying to profit off the community MySQL has created. This is open source and should remain open source.
There is a fork of MySQL called Drizzle which is run by the chief architect of MySQL before sun bought them. From what I remember reading a while ago it's being specifically targeted at being used for Web Backends.
I approached this article thinking about how evil oracle is. But I left it hoping oracle does this well. They had a good point about no price increases in the last 6 years.
I'm not a fan of monetizing software through support, but I would love see some people hitting it big and proving me wrong.
It's a highly misleading statement. Oracle didn't own MySQL for 6 years so they couldn't have raised MySQL prices even if they wanted to.
What it really means is that MySQL price was the same for past 6 years, when it was owned by MySQL, AB and then Sun, but as soon as ink dried on Sun acquisition, the first thing that Oracle did was to rise the prices.
Have they even released any new, improved version?
If they haven't raised prices in 6 years, that probably means that they thought customers would switch to Oracle if they did. MySQL didn't want that to happen; Oracle probably does.
Seems like the perfect time for those considering switching to read my Demystifying PostgreSQL article from this month's php|architect Databases issue. http://www.phparch.com/magazine/2010/september/.
Unfortunately, I can't post it on the web outside the magazine for 3 months.
As the drizzle guys have pointed out in detail there are really two mysql customer bases. One wants to treat it as a sellable/supportable component of ISV packages, i.e. as a cheaper replacement for MSSQL/Oracle. The other wants to use it for "internet scale" things (high traffic websites, saas providers, etc). This price hike really only affects the former, and frankly, who cares, those guys have controlled the feature roadmap for 3+ years anyway they're welcome to pay for the mess they've created.
Those of us who build websites will be just fine with Percona until drizzle is ready (or maybe even forever).
if customers did leave in mass exodus, wouldn't Oracle get the benefit of effectively closing down mySQL, without the adverse publicty, while also increasing revenue?
Sounds like win-win (where both wins are for oracle, rather than the conventional meaning of both parties winning.)
The silver lining. Hopefully, this will mean that more projects will target Postgres as a primary deployment platform.