![]() |
Services | Software | Partners | Articles | Contact |
Benchmarking PostgreSQL vs. MySQL performance using Drupal 5.xDrupal has long supported both MySQL and PostgreSQL as database backends. The vast majority of Drupal users run it on MySQL though. Support for PostgreSQL in Drupal has suffered from non-contiguous maintainership, with someone taking it for a year, then disappearing, then someone else comes by and takes it up, ...etc. There has even been concerns among core developers about PostgreSQL holding back patches that work fine in MySQL. But, this article is not about whether we should drop PostgreSQL (we should not!), or its state of support in Drupal, so please do not comment on those aspects. Benchmarking Drupal on PostgreSQL vs. MySQLThis article is about performance of Drupal on both MySQL and PostgreSQL. I was Intrigued by a post by Jamon Camisso that started out with the observation that PostgreSQL is significantly faster on Drupal than MySQL, contrary to the commonly held view based on past observations. There are lots of comments in that thread from PostgreSQL advocates, as well as some corrections pointing out that MySQL must be misconfigured on that server. So, I decided to do a controlled benchmark of Drupal 5 on both databases to see which database is faster. Benchmark setupFor the hardware, I used my development server, which is an AMD64 X2 4400+ dual core running at 2.2 GHz, with 2 GB of RAM. This server runs Ubuntu Server 7.04 Fesity Fawn x86_64. MySQL is 5.0.38, and PostgreSQL is 8.2.5, which are what comes with this distro version. PHP is 5.2.1, with APC 3.015 installed and configured. Drupal setupDrupal is the latest 5.x DRUPAL-5 tagged version from the repository. The setup was a multisite install, so both sites are running from the same code base. One was configured for MySQL and one for PostgreSQL. PostgreSQL configurationSetting up a PostgreSQL database took some digging, but once the steps are figured out, they are fairly simple. First, PostgreSQL would not start, and complains about the SSL certificate. FATAL: could not load private key file "server.key": key values mismatch This is caused by the default SSL certficate delivered with Ubuntu is not a valid one. To solve this, just edit /etc/postgresql/8.2/main/postgresql.conf and comment out the line that says ssl = true. Now PostgreSQL will start. No other changes from the default settings provided by Ubuntu are made. Creating a PostgreSQL user and databaseThe steps to create a database in PostgreSQL are documented in the INSTALL.pgsql.txt that comes with Drupal. However, I used a slightly different approach, with the same end result. For creating a user and database, assuming we want a user called username and a password of password123, you do the following in a shell: $ sudo bash # su - postgres $ createuser -DRS username $ createdb -O username drupal $ psql ALTER USER USERNAME WITH UNENCRYPTED PASSWORD 'password123'; Once the database is created, you just stick the following link in settings.php: $db_url = 'pgsql://username:password123@localhost/drupal'; Then, you visit install.php so Drupal will create the tables for you in the database. Of course, you can use install.php and enter the data as well, which is easier for most users. MySQL configurationThe default configuration supplied with Ubuntu was used. This has the query cache turned on by default. All the tables are MyISAM.
Running the benchmarks
|
| Database | MySQL | PostgreSQL |
| Total time taken for front page (milliseconds) | 63.89 | 130.44 |
| Time for front page queries (milliseconds) | 15.07 | 67.81 |
| Concurrency of 1 (requests per second) | 18.23 | 10.82 |
| Concurrency of 5 (requests per second) | 32.84 | 16.76 |
MySQL's query cache
MySQL's query cache makes its performance better. This can be demonstrated by restarting MySQL, then visiting the home page of the site and seeing the query time in devel's output. However this is not as marked as what PostgreSQL takes.
Right after MySQL starts (no queries cached yet):
Page execution time was 92.74 ms. Executed 98 queries in 30.04 milliseconds.
Subsequent access (queyr cache kicks in).
Page execution time was 63.61 ms. Executed 98 queries in 10.38 milliseconds.
Conclusion
The definite conclusion from these benchmarks is that out of the box, MySQL is configured to run faster than PostgreSQL.
Future considerations
PostgreSQL can probably be made better by further tuning. I am willing to repeat these benchmarks if the PostgreSQL community are willing to guide me with what parameters need to change in order to make its performance better. Please comment below if you have info on this.
Updates
1. I attached the configuration files used for both MySQL and PostgreSQL for anyone who wants to share configuration options that would tune performance further.
2. You can also see a more tweaked MySQL MyISAM configuration file for large web sites for reference (not used for this benchmark).
| Attachment | Size |
|---|---|
| postgresql-configuration.txt | 508 bytes |
| mysql-configuration.txt | 741 bytes |


How about a REAL test.
Why not write something in jmeter or something like that that randomly grabs pages, and WRITES some new ones out every so often.
With lots of threads, and a fair number of them updating, you'll likely find pgsql keeping up just fine.
Then, implement mem_cache for the pgsql side (you can abstract it to work for both mysql and pgsql btw) so that the caching is fair, and also available to real drupal users.
As it is, this test tests very little. The ability to deliver the same front page over and over, even with 5 or more threads, means VERY little. It's like measuring the maximum RPM of an engine as a test. My car can rev to 6000 RPM, a locomotive can rev to 1800 RPM. guess which can pull a heavier load?
Tests like this will always
Tests like this will always show the same: mysql is faster. And it is, single user, single processor. The point however is that PostgreSQL scales much better. See this page and many other tests which prove over and over again that PostgreSQL scales perfectly.
Not really
This was not single user. This box has 2 cores, and you can see tests that have concurrency of 5 above.
There are Drupal sites that get 600,000+ page views a day on MySQL MyISAM (not even InnoDB), so MySQL does scale too.
--
2bits -- Drupal consulting
You seem to forget that it
You seem to forget that it also depends on how the SQL is written. Also have you made sure your drupal installation makes use of proper indexes? try running the SQL used within drupal with EXPLAIN ANALYZE and see if it uses any indexes, etc.
Also conf files play an important role, this I personally am not that great in, but I know with proper indexing, you can get CRAZY speed advantages.
Ive had both mysql and postgres perform better with proper indexing.
First MySQL was quicker, then someone asked me to index in a certain way and re-run the queries. My queries went from 180ms in mysql down to 95ms. PG went from 210ms down to 67ms.
Apachebench flawed for concurrency?
I'm not certain on this, but I've read several times that apachebench is flawed in concurrency tests because it's single-threaded. I haven't tried Flood however.
localhost?
Did you run these tests _on_ the server? When you get a higher # of requests/s for higher concurrency settings, it might indicate that your network connection is the limiting factor.
Also, I don't see the value of out-of-the-box performance; it's the tweaked performance that matters.
agreed - out of the box is of little value
i agree with heine and others. it is simply not useful for most of your readers to compare with out of the box configurations. people who need high performance can afford to buy a book and read web sites like this for configuration tips. your test is valid, it is just not useful. my .02.
Hold on ...
Well, not all sites can afford tuning. Forget the top 10 Drupal sites, and those with several hundred thousands of page views a day. The vast majority of sites fall into this second tier (dedicated and VPS ones, and even shared hosting ones that choose PostgreSQL).
Anyway, I am working with Bill Moran to tune PostgreSQL further. We tried increased the shared_buffers to 200M. The size of the database is 100M, but that still did not help.
Stay tuned, it is not over yet.
--
2bits -- Drupal consulting
Any update
Hi Khalid,
Was wondering if there was any more tunning done on the PostgreSQL db and did it help to bring it inline with the speed of MySQL.
I'm at a point of selecting a db for my web app, so this info would be good to have. I have read many articles and blog entries and they all seem to point that the newer version of PostgreSQL is just as fast as MySQL.
If there is an update to your benchmark, please post it.
Thanks,
Amin
Yes and no
Yes, the tests were run on the server (i.e. ab on the same server that runs Drupal and the database). So, network is not an issue here.
As for out of the box experience, it is very important for the average user. They don't have the knowledge, time or money to tweak a system to squeeze the maximum performance.
I am looking for ways to improve PostgreSQL, so anyone with knowledge on how to do that is welcome to share configuration options to do so.
--
2bits -- Drupal consulting
This could say more about Drupal and/or PHP than MySQL or PG
I have deployed Drupal 5x with MySQL and PostgreSQL and the latter has always felt faster. Admittedly, this was only an impression based upon using the site rather than running an artificial benchmark on it. However, I have always ended up using MySQL, despite how much I dislike that product, with Drupal only because support for PostgreSQL is spotty at best for anything but core modules. The results you obtained may have more to do with poor support of PostgreSQL by PHP and/or Drupal than MySQL's supposed superiourity.
InnoDB
I'm no Postgresql expert but from my understanding this is not the comparison typically talked about. MyISAM is faster at a functionality cost.
What I usually read about in the comparison is InnoDB vs. Postgresql. These two setups share from of the same functionality such as row level locking rather than table level locking. This is the use case I'm most interested in. From my basic understanding, this is the more appropriate test case.