For a long time now, most who’ve used both have felt that Postgres was a better database than MySQL, myself included. But until now, the stick that MySQL keep beating Postgres over the head with was performance. MySQL might be a toy database (okay, it’s moving away from that these days, but only in the last few versions and that’s not really enough dev time to be stable enough for critical stuff), but it was fast on cheap hardware, and for pragmatic web development, that meant it beat out Postgres every day of the week.
Basicly, for the first time in a seriouly major benchmark, postgres not only outperformed mysql, but it nearly matched oracle (which was running on hardware that cost more than twice as much).
There’s also this earlier post, which basicly showed that Mysql on a single-CPU machine starts off faster than Postgres, but falls off as the number of concurrent users
rises, until it’s way behind postgres, which remains pretty invariant as the number of users rises. It also shows that postgres takes advantage of multiple CPUs better than MySQL does (up to 16 CPUs anyway, where the postgres team say they still have work to do).
Something to think about. Do you expect to ever have more than one or two users on your site? Better start with postgres so, and save yourself the cost and hassle of a later switch (I don’t care how good your database abstraction layer is, no DAL is so good that you don’t have to change your app when you switch database. Maybe more on that later.)
Hi!
You wrote:
“MySQL might be a toy databas … but it was fast on cheap hardware, and for pragmatic web development, that meant it beat out Postgres every day of the week.
[link: Not any more…]”
Please take a look at the benchmarks. You will notice that they are certainly not using “cheap hardware”. Quite the opposite…
Also, you wrote:
“Basicly, for the first time in a seriouly major benchmark, postgres not only outperformed mysql, but it nearly matched oracle (which was running on hardware that cost more than twice as much).”
Please note that the PostgreSQL benchmark nowhere compared against MySQL, as MySQL did not submit any benchmark results this quarter, so statements like “postgres not only outperformed mysql” are a) not relevant and b) seem to intentionally inflame. I’m not quite sure why Josh mentioned MySQL in his article, but I have to presume it’s because of way early (1998) benchmarks that didn’t show PostgreSQL in a favorable light compared to MySQL. Regardless, MySQL to PostgreSQL is not compared in the benchmarks, but rather the benchmarks show that a very good performance rating can be achieved compared to Oracle on similar, but lower-cost hardware using PG 8.2.
I was one of the first to congratulate the PG dev team for the benchmarks (see my post: http://www.jpipes.com/index.php?/archives/181-Congrats-to-the-PostgreSQLEnterpriseDBSun-Team-for-Benchmarks.html) but let’s make sure to be factually correct when discussing them.
Cheers,
Jay Pipes
Jay,
When I said that Postgres is no longer beaten by MySQL for pragmatic web development, I didn’t mean that the benchmark showed that postgres now beats mysql on cheap hardware (though that would be an interesting benchmark to run); I mean that a pragmatic developer is going to look at how many people are expected to concurrently use the site and if that number is hoped to be larger than one, they’ll note that Postgres’s better load characteristics have now been confirmed in a seriously heavy benchmark.
On the second point, you’re right in that MySQL isn’t directly compared to Postgres by those benchmarks, but also right in that it has been in the past — meaning that this result shows that major progress has been made.
However, I’d like to see something more definitive. A properly tuned, properly configured MySQL 5 database versus a properly tuned, properly configured Postgresql 8.2 database, running a heavy real-world app with high numbers of concurrent users, on identical hardware. I’d put my money on Postgres to come out on top, but the margin and the speed-vs-users curves would be the interesting bit.