MySQL vs. PostgreSQL: The 2010 Reality Check

It has been a rough year for the open source database community. With Oracle closing its acquisition of Sun Microsystems in January, the uncertainty surrounding MySQL is palpable. I've spent the last six months migrating nervous clients from legacy setups, and the question I get in every meeting is the same: "Should we stick with MySQL, or is it finally time to move to PostgreSQL?"

There is no silver bullet, but there are wrong answers. If you are still running default MyISAM tables on a high-concurrency e-commerce site, you are begging for table-locking disasters. Conversely, if you are using PostgreSQL for a simple read-heavy blog without tuning your shared buffers, you are wasting RAM.

The MySQL Proposition: Speed vs. Reliability

MySQL 5.1 is ubiquitous. It is the 'M' in LAMP. But out of the box, it is a loaded gun pointed at your foot. The default storage engine, MyISAM, is fast for reads but lacks transaction support and performs table-level locking. One long UPDATE query freezes the entire table for everyone else.

For any serious application hosted in Norway—whether it's a billing system complying with the Personopplysningsloven (Personal Data Act) or a high-traffic media site—you must use InnoDB. It provides row-level locking, ACID compliance, and crash recovery.

Sysadmin Pro Tip: If you are running MySQL 5.1 on a VPS, stop everything and check your my.cnf. If innodb_buffer_pool_size is set to the default 8MB, your performance will tank as soon as your dataset grows. Set it to 70-80% of your available RAM on a dedicated database server.

Here is the configuration that saves careers:

[mysqld]
# Use InnoDB as default
default-storage-engine = InnoDB

# The most important setting for write performance vs safety
# 1 = safest (fsync on every commit)
# 2 = faster (fsync once per second), risks 1 sec of data loss on OS crash
innodb_flush_log_at_trx_commit = 1

# Essential for heavy concurrent loads
innodb_thread_concurrency = 8

PostgreSQL 9.0: The New Heavyweight Champion

September 2010 changed everything. The release of PostgreSQL 9.0 introduced built-in Streaming Replication and Hot Standby. Before this, setting up replication in Postgres was a nightmare involving Slony-I or risky WAL shipping scripts. Now, it is arguably more robust than MySQL's statement-based replication.

PostgreSQL is strict. It cares about data integrity more than it cares about your feelings or your sloppy code. If you try to insert a string into an integer field, MySQL might truncate it and warn you; Postgres will throw an error and abort the transaction. For financial data or applications requiring strict referential integrity, this isn't optional—it's mandatory.

Performance Benchmarking: The I/O Bottleneck

Databases live and die by disk I/O. It doesn't matter if you choose MySQL or Postgres if your underlying storage is choking. In a virtualized environment, "steal time" and I/O wait are the enemies.

Most budget VPS providers in Europe oversell their storage arrays. They put fifty customers on a single SATA raid array. When your neighbor starts a backup, your database latency spikes from 2ms to 500ms.

This is why we built the CoolVDS platform differently. We utilize 15k RPM SAS RAID-10 arrays and the emerging generation of Enterprise SSDs for caching tiers. We also use KVM (Kernel-based Virtual Machine) virtualization rather than OpenVZ. With KVM, your RAM and disk operations are isolated. A noisy neighbor cannot steal your inode cycles.

The Verdict: Which One?

Choose MySQL if you are running a CMS like WordPress, Joomla, or Drupal that was built for it, or if your team is already deeply familiar with the LAMP stack. Just ensure you tune InnoDB correctly.

Choose PostgreSQL if you are building a custom application, require complex geospatial queries (PostGIS is incredible), or if data integrity is paramount. With version 9.0, the replication barrier is gone.

Latency and Location

Finally, consider the physics. If your users are in Oslo or Bergen, hosting your database in a US datacenter adds 100ms+ of latency to every query round-trip. For a complex page load with 20 SQL queries, that adds two full seconds of waiting time.

CoolVDS infrastructure is peered directly at NIX (Norwegian Internet Exchange). Keeping your data within Norwegian borders also simplifies compliance with the Data Inspectorate (Datatilsynet). Don't let network hops kill your database performance.

Ready to test the new Postgres 9.0 replication? Deploy a high-performance KVM instance on CoolVDS today and experience true I/O isolation.