

The State of MySQL: The Elephant in the Room - billymeltdown
http://www.zetetic.net/blog/2009/02/10/the-state-of-mysql-the-elephant-in-the-room

======
artificer
When FreeBSD was released, at 27 Feb 2008, Kris Kennaway posted a nice
slideshow that includes some PostgreSQL and MySQL benchmarks:

<http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf>

Database-wise, they should be still considered recent. PostgreSQL features
impressive scaling there.

------
iamelgringo
I just launched a Windows-Apache-Postgres-Python/Django stack on EC2 using
Elastic block for the postgres database storage. That install worked like a
charm, and I'm running www.cuuute.com on it right now.

I had an urge to try MySQL as a database, and I found an installer bug that
broke the installation and messed up my server. The installer died giving me a
"MySQL can't install as a service" error, and then not allowing me to go
forward. So, I did that a couple of times. I then realized that the installer
had installed MySQL each time I ran the installer, but didn't complete it.

I Googled for an hour and couldn't find a resolution to the issue, just a
bunch of forums= threads asking for help on the same problem for the past 9
months.

Postgres for the win. BTW EC2 + Elastic block rocks like Dokken for a WAPP
setup.

~~~
blasdel
Why do you want to use Windows if you're not using SQLServer, .NET, or other
nice stuff that doesn't run elsewhere?

------
davidw
I've always used Postgres, but don't think the copyright assignment thing is
_that_ big a problem. The FSF does that, and it seems to work out ok.

~~~
ocskills
I think there is a big difference between the two.

The FSF uses copyright assignment to ensure that open source code is not
legally encumbered.

MySQL uses the copyright assignment so they can sell code contributed by open
source developers in their commercial platform without compensating the
authors.

~~~
davidw
Yeah, that's a good point. Well, like I said, I am firmly in the Postgres camp
in any case. I've never enjoyed discovering things about Mysql like the fact
that even InnoDB doesn't allow you to modify the DB transactionally.

~~~
ruby_roo
Wait... what?

Looks like InnoDB supports transactions, no?
[http://dev.mysql.com/doc/refman/5.1/en/innodb-transaction-
mo...](http://dev.mysql.com/doc/refman/5.1/en/innodb-transaction-model.html)

~~~
davidw
<http://adam.blog.heroku.com/past/2008/9/3/ddl_transactions/>

"MySQL doesn’t support DDL transactions;"

Meaning you can't change the schema transactionally. InnoDB handles data
transactions ok, but I hadn't realized that it doesn't handle schema changes.
It seems like I'm always discovering some little nasty about Mysql when I am
forced to use it.

------
tdavis
It feels good when your higher-quality, smaller bandwagon starts to overtake
the giant, rickety one.

------
wheels
Wait, was there supposed to be some content in there? That post was basically
flamebait. You can sum up everything useful in there with news that's already
made the rounds, "MySQL founders left Sun."

------
zmimon
My beef about MySQL used to be technical but in the last 3 - 4 years that has
evaporated, and now it is purely about the license. I cannot understand why
anybody uses a database for which the only official client side drivers are
GPL, rather than (at least) LGPL. Unless you really truly intend that your own
app will be licensed GPL and so will every other application / piece /
component/ that ever needs to interact with your database in any way, it is a
ball and chain around your neck which seems crazy to place there when there
are other equally good alternatives.

------
jasonkester
At the moment, it's not even possible to download and install MySQL anymore.

I was setting up a Wordpress install a week ago, so I headed over to MySQL.org
and hit the download link. They won't let you even download it without having
your company "Reviewed" these days. So I filled out my info and was told I'd
hear back when they were ready.

That was a week ago. No word back. I still can't even download it.

I could never understand anybody would use MySQL for anything business
critical. Now it seems that nobody is allowed to use it for anything at all.

~~~
jm4
The article presents the problem as mostly organizational and not with the
actual software. Maybe the parent comment was a little off topic, but it also
serves to further illustrate the problem.

The parent commenter was familiar enough with the product to know he wanted to
use it, but the project and its strategy is so disorganized that he walked
away empty handed. Now he's unknowingly spreading misinformation to other
people who may be deciding whether or not to use the product.

This is really a perfect example of what the article discussed. MySQL tries to
present itself as an open source organization but does not function as such,
resulting in confusion and frustration among contributors. The fact that
consumers are also confused over what they can and can't do only goes to show
that these mixed messages have permeated the entire organization.

~~~
radu_floricica
This is an ooold problem, and I don't mean organizational, but people
confusing the download link. I think I did it first at least 5 years ago.
Still, the GP should be downmodded at least to a pale gray, maybe -2, and stay
there. An honest mistake is still a mistake, and it's our job to mark it
clearly as such.

As far as the project being disorganized, I'd much rather think this comes
from the old days when men were men, documentations came in man pages and
people were ashamed of not RTFM. I know I held my head down for at least a
week after that.

------
amix
I have tried to search for MySQL vs. PostgreSQL benchmarks and most of them
date to 2007. Are there any recent benchmarks that compare these databases?

I personally use MySQL and I think it's an OK database (performance and
installation wise) and I think it's a bit risky to jump on PostgreSQL when
most others use MySQL (e.g. Flickr, Facebook, Yahoo, Google just to name a
few).

~~~
newt0311
Benchmarks between DBs are pretty rare because they are so difficult to
control for. The configurations make a big difference. One set of benchmarks
is here: <http://tweakers.net/reviews/657/6> but thats in 2006. Also, MySQL
has known fatal bugs in the production release so mysql isn't exactly a safe
choice.

~~~
staunch
> _Also, MySQL has known fatal bugs in the production release so mysql isn't
> exactly a safe choice._

Outright FUD.

~~~
newt0311
Not quite:

MySQL GA release with known crashing bugs:
<http://news.ycombinator.com/item?id=380092>

Comparison of MySQL and PostgreSQL releases:
<http://news.ycombinator.com/item?id=381899>

------
dabeeeenster
Postgres doesn't have native replication AFAIK - what are the state of the
plugin projects that provide this functionality, and how do they rate against
the MySQL clustering?

~~~
ocskills
Feature wise, I don't think there are many things that MySQL can do that
PostgreSQL can't given a proper configuration. The main difference is that
PostgreSQL doesn't include things like clustering as part of the core
distribution like MySQL. They are often released and maintained as third-party
add-ons to the core platform.

For instance, PostgreSQL has a number of projects that facilitate clustering.
Slony-I is a stable open source replication framework
(<http://www.slony.info/>). PGCluster provides a multi-master replication
facility (think Oracle RAC). PGpool allows front end load balancing of
connections.

~~~
rcoder
AFAIK, none of the add-on replication mechanisms you mentioned can guarantee
total consistency across multiple database backends: OIDs are not replicated,
and there are no hard guarantees against external modifications taking your
databases out of sync.

As an alternative, you can use Point-In-Time-Recovery (PITR), also known as
"log shipping", to transfer copies of your write-ahead log files from a master
server to a warm standby. PITR allows you to have an exact replica of your
master database, modulo whatever delay you incur in the log transfer itself.

For those who haven't aren't familiar with write-ahead logs, they function
much like the logging in modern filesystems: changes are written there before
being flushed to disk, so any incomplete transactions can be replayed from the
logs if the server goes down unexpectedly.

Of course, the log-shipping method doesn't allow your secondary server to
serve as a read-only replica as MySQL's built-in replication does. Largely for
that reason, (depending on your workload and requirements, of course) MySQL
may be a better choice. However, I've found Postgres PITR to be an excellent
option for low to medium-traffic databases in those cases where I'm willing to
trade the possibility of the loss of a few seconds' updates for guarantees
that my DDL, object identities, and constraints will be maintained
consistently between my replicas.

For those who are curious, the PostgreSQL docs online have a decent
introduction into the use of write-ahead logs for replication and backups:

<http://www.postgresql.org/docs/8.2/static/wal.html>

------
charlesju
Relational databases are so overrated.

