MySQL vs PostgreSQL: Surviving the Database Wars of 2011
It has been over a year since Oracle closed its acquisition of Sun Microsystems, and the tremors are still being felt in server rooms across Oslo and the rest of Europe. For years, the LAMP stack was the default choice. Linux, Apache, MySQL, PHP. It was simple. It worked.
But the landscape in late 2011 is different. We are seeing a massive migration of serious architectural logic into the database layer. With the release of PostgreSQL 9.1 in September, offering synchronous replication, and MySQL 5.5 finally making InnoDB the default engine, the choice is no longer about "ease of use" versus "features." It is about data integrity versus raw read speed.
If you are deploying a VPS in Norway today, you aren't just picking a database; you are picking a philosophy. Do you trust the Dolphin (and its new corporate overlord), or do you join the Elephant?
MySQL 5.5: The Speed Demon Matures
Let's be fair: MySQL 5.5 is a significant leap forward. The biggest change is that InnoDB is now the default storage engine. Gone are the days of explaining to junior developers why MyISAM table locking is killing their site performance during backups. With InnoDB, we finally get reliable ACID compliance and row-level locking out of the box.
However, MySQL is still fundamentally built for reads. It shines in web scenarios where you have a 90/10 read/write split. If you are running a high-traffic media site or a CMS, MySQL on a tuned Linux VPS is hard to beat for raw throughput.
Pro Tip: If you have upgraded to MySQL 5.5, stop running with default buffers. On a CoolVDS instance with 4GB RAM, you must tune your my.cnf to leverage the memory:
[mysqld]
innodb_buffer_pool_size = 2G
innodb_flush_log_at_trx_commit = 2 # Faster, slight risk on OS crash
query_cache_size = 64M
PostgreSQL 9.1: The Integrity King
While MySQL focuses on speed, PostgreSQL has focused on being bulletproof. The release of version 9.1 a few months ago changed the game for high-availability setups. Previously, replication in Postgres was asynchronousâfast, but with a window for data loss if the master node melted down.
Now, we have Synchronous Replication. This guarantees that a transaction is not considered committed until it is written to at least one standby server. For financial applications or systems handling sensitive data subject to the Norwegian Personopplysningsloven (Personal Data Act), this is non-negotiable.
We are seeing more developers switch to Postgres for its rich feature set: GIS support (PostGIS), true serializable isolation levels, and the ability to handle complex joins without choking.
# postgresql.conf for High Availability
wal_level = hot_standby
max_wal_senders = 5
synchronous_standby_names = '*' # Enforce sync replication
The Hardware Factor: Why I/O Matters
You can tune your config files until you are blue in the face, but if your underlying storage is slow, your database will crawl. This is the bottleneck most providers hide. They oversell spinning rust (SATA HDDs) and put fifty tenants on a single RAID array.
When a neighbor starts a backup, your "Wait I/O" spikes, and your site hangs. This is the "noisy neighbor" effect.
At CoolVDS, we have moved aggressively to Pure SSD (Solid State Drive) storage arrays. The difference in IOPS (Input/Output Operations Per Second) is not linear; it is exponential. While a 15k RPM SAS drive might give you 180 IOPS, our SSD arrays push thousands. For a database doing random seeksâwhich is exactly what databases doâSSD is the only logical choice in 2011.
Comparison: When to Choose Which?
| Feature | MySQL 5.5 | PostgreSQL 9.1 |
|---|---|---|
| Replication | Asynchronous (Fast, eventual consistency) | Synchronous (Zero data loss, higher latency) |
| Storage Engine | Pluggable (InnoDB, MyISAM) | Unified Transactional |
| Best For | Web Apps, CMS (WordPress/Drupal) | Complex Data, Financials, GIS |
| License | GPL (Oracle owned) | BSD/MIT (Community owned) |
Data Sovereignty and Latency
Beyond the software, where you host matters. With the US Patriot Act allowing American authorities to access data hosted on US-owned clouds (even if the server is in Europe), many Norwegian businesses are rightly concerned about data privacy. The Datatilsynet is watching closely.
Hosting on CoolVDS ensures your data stays within Norwegian jurisdiction. Furthermore, if your customer base is in Scandinavia, physics is on your side. Pinging a server in Oslo from Bergen takes milliseconds. Pinging a cloud server in Virginia takes 100ms+. In the database world, that latency kills application performance.
Conclusion
If you need simple, read-heavy speed for a blog or forum, MySQL 5.5 on CentOS 6 is a rock-solid choice. But if you are building the next complex SaaS platform and data integrity is paramount, PostgreSQL 9.1 is the superior technical decision.
Whatever engine you choose, don't strangle it with slow spinning disks. Give your database the I/O headroom it deserves.
Ready to test the difference? Deploy a high-performance SSD VPS instance on CoolVDS today and experience database performance without the I/O wait.