PostgreSQL 9.0 vs MySQL 5.5: The Database Battle for 2011
It has been a turbulent year for the open-source database community. With Oracle completing its acquisition of Sun Microsystems back in January, many of us in the sysadmin trenches have been nervously watching the future of MySQL. Meanwhile, the PostgreSQL Global Development Group just dropped a bombshell in September with version 9.0, finally bringing native streaming replication to the table.
I’ve spent the last month migrating a high-traffic e-commerce client from a legacy MySQL 5.0 setup to a modern architecture. The debate over which engine to use was heated. If you are building for the Nordic market, where latency to the NIX (Norwegian Internet Exchange) and strict adherence to the Personopplysningsloven (Personal Data Act) are non-negotiable, the choice isn't just about syntax. It's about survival.
The MySQL 5.5 Landscape: Fast, Popular, but Fragmented
Let's be honest: MySQL is the default for a reason. It powers the LAMP stack, it’s what every junior developer learns first, and for read-heavy workloads (like WordPress or simple CMS sites), it screams.
However, the default configuration on most distributions is still dangerous. By default, many installs still lean on MyISAM, a storage engine that lacks transaction support and foreign keys. If your server crashes during a write, good luck with that table repair.
If you stick with MySQL in late 2010, you must force InnoDB. With the release of MySQL 5.5 (currently a Release Candidate, likely GA any day now), InnoDB becomes the default. But if you are still on 5.1, you need to intervene manually.
[mysqld]
# Stop using MyISAM for serious data
default-storage-engine = InnoDB
innodb_file_per_table = 1
innodb_buffer_pool_size = 512M # Adjust to 70-80% of RAM on dedicated DB servers
The Oracle Fear Factor
There is chatter in the community about forking. Michael Widenius (the creator of MySQL) has started the MariaDB project. It's early days, but if Oracle tightens the license, we might all be migrating soon. For now, MySQL is still king of speed for simple reads, but the crown is slipping.
PostgreSQL 9.0: The "Real" Database Finally Grows Up
For years, the knock against Postgres was that replication was a nightmare. You had to use messy triggers like Slony-I. That ended in September 2010. PostgreSQL 9.0 introduced Hot Standby and Streaming Replication.
This is a massive shift. We can now run a primary server for writes and offload read-heavy queries to a replica with standard, built-in tools. For financial applications or anything requiring strict ACID compliance, Postgres is miles ahead. It doesn't silently truncate data to fit a field like MySQL sometimes does; it throws an error. It forces you to be a better developer.
Pro Tip: Using PostgreSQL 9.0? Enable the new replication features inpostgresql.confimmediately to future-proof your cluster.
wal_level = hot_standby
max_wal_senders = 5
Storage I/O: The Bottleneck No One Talks About
You can tune shared_buffers or query caches all day, but database performance in 2010 ultimately dies at the disk level. Most budget VPS providers in Europe are still stuffing 40 customers onto a single SATA 7.2k RPM drive. The moment one neighbor runs a backup, your query latency spikes to 500ms.
This is why we architect CoolVDS differently. We don't use consumer-grade drives. We utilize high-speed SAS RAID-10 arrays and have recently started deploying Enterprise SSDs for our high-performance tier.
In our benchmarks, an SSD-backed VPS handles 10x the random write operations (IOPS) of a standard SATA VPS. If you are running a database, you are I/O bound. Don't cheap out on storage.
Data Sovereignty and Latency
If your target audience is in Oslo, Bergen, or Trondheim, hosting in Texas (or even Germany) adds unnecessary milliseconds. With the growth of fiber optics, users expect instant page loads.
Furthermore, we have to consider the Datatilsynet (Norwegian Data Protection Authority). While the US Safe Harbor framework exists, keeping data on Norwegian soil simplifies compliance with the Personal Data Act significantly. You know exactly where your physical bits reside.
Comparison: Which One to Choose?
| Feature | MySQL 5.1/5.5 | PostgreSQL 9.0 |
|---|---|---|
| Best For | Websites, CMS, Read-heavy apps | Complex Data, Financials, GIS |
| Replication | Statement-based (Standard) | Streaming WAL (New in 9.0!) |
| Strictness | Loose (allows bad data sometimes) | Strict (ACID compliant) |
| Joins | Nested Loop only | Hash Joins, Merge Joins |
Final Verdict
If I am deploying a WordPress blog or a forum, I will stick with MySQL (with InnoDB enabled). It is lightweight and ubiquitous.
But for the project I deployed last week—a custom inventory system for a Norwegian logistics firm—we went with PostgreSQL 9.0 on CoolVDS. The combination of strict data integrity, the new replication features, and the low latency of our Oslo-optimized routing made it the only professional choice.
Don't let legacy spinning disks kill your database performance. Spin up an SSD-accelerated instance on CoolVDS today and see what your queries feel like with proper I/O headroom.