MySQL 5.5 vs. PostgreSQL 9.0: Stop Defaulting to 'M' in LAMP

I've spent the last three nights rebuilding a crashed MyISAM table for a client who thought "databases just work." It’s a painful reminder that the choice between MySQL and PostgreSQL isn't about preference anymore—it's about architecture. With the recent release of MySQL 5.5 and PostgreSQL 9.0, the landscape has shifted. If you are still deploying databases like it's 2008, you are building technical debt.

Most developers in Norway just run apt-get install mysql-server because it’s easy. That’s fine for a personal blog. But if you are building a transactional application targeting the European market, you need to look at the metal, the config, and the data integrity laws.

The MySQL 5.5 Shift: InnoDB is Finally King

For years, MySQL's default storage engine was MyISAM. It was fast for reads but terrible for data integrity. If the server power cycled, you prayed. Table-level locking meant that one write operation blocked every user reading that table. On a high-traffic site, that's death.

The big news in 2011 is that MySQL 5.5 has made InnoDB the default engine. This brings ACID compliance and row-level locking to the masses.

Sysadmin Note: If you are upgrading from 5.1, check your my.cnf. You need to tune innodb_buffer_pool_size to about 70-80% of your available RAM on a dedicated VPS. If you leave it at the default 8MB, your performance will tank.

When to choose MySQL 5.5:

• Read-Heavy Web Apps: WordPress, Drupal, and Joomla are highly optimized for MySQL.
• Simple Replication: Master-Slave replication in MySQL is battle-tested and simple to set up.
• Developer Familiarity: Every PHP developer knows `mysql_query` (though you should be using PDO by now).

PostgreSQL 9.0: The "Oracle Killer"

While MySQL focuses on speed for the web, PostgreSQL has always focused on correctness. With version 9.0, they introduced Streaming Replication and Hot Standby. This is massive. Previously, high-availability Postgres was a nightmare of Slony triggers or log shipping. Now, it's native.

I recently migrated a financial reporting tool from MySQL to Postgres because of Common Table Expressions (CTEs) and complex JOINs. In MySQL, the query took 4 seconds. In Postgres, with proper indexing, it took 200ms. If your data is relational and complex, MySQL’s optimizer often chokes.

Configuration Criticality

Postgres is conservative out of the box. You must edit postgresql.conf. A standard mistake is leaving shared_buffers too low. On a CoolVDS instance with 4GB RAM, set this to 1GB immediately.

# /etc/postgresql/9.0/main/postgresql.conf
shared_buffers = 1024MB
effective_cache_size = 3072MB
work_mem = 32MB
maintenance_work_mem = 256MB

Storage I/O: The Bottleneck No One Talks About

You can tune your config all day, but if your disk I/O is slow, your database is slow. This is physics.

In traditional shared hosting, your database fights for disk access with 500 other users. This causes "I/O Wait"—where your CPU sits idle waiting for the hard drive to spin. I've seen load averages spike to 50.0 not because of traffic, but because of disk contention.

This is why we architect CoolVDS differently. We use KVM virtualization. Unlike OpenVZ (which many budget hosts use), KVM isolates your resources. We are also rolling out enterprise-grade SSD storage across our nodes. In 2011, SSDs are expensive, but the random read/write speeds are 100x faster than traditional 15k SAS drives. For a database, that low latency is everything.

Data Sovereignty in Norway

Let's talk legal. Under the Personal Data Act (Personopplysningsloven) and the guidance of Datatilsynet, you are responsible for where your user data lives. Hosting customer data in the US (under the Patriot Act) introduces risks that many Norwegian companies want to avoid.

Keeping your database on servers physically located in Oslo or nearby European hubs ensures two things:

1. Compliance: It simplifies your adherence to Norwegian privacy standards.
2. Latency: The round-trip time (RTT) from Oslo to a server in Texas is ~140ms. To a server in Oslo, it's ~10ms. For a database application making 50 queries per page load, that latency compounds fast.

The Verdict

Pick MySQL 5.5 if: You are running a standard web application, want easy scaling, or are constrained by legacy PHP code.

Pick PostgreSQL 9.0 if: You value strict data integrity, need complex queries, or rely on features like GIS (PostGIS).

Whatever you choose, don't run it on oversold hardware. Database performance relies on low-latency I/O and dedicated RAM. Spin up a KVM instance on CoolVDS today and see the difference dedicated resources make for your query times.