The Holy War is Over (It's Just Physics Now)

It has been over a year since Oracle acquired Sun Microsystems, and the panic in the open-source community hasn't fully settled. Is MySQL doomed? Is PostgreSQL finally fast enough for high-traffic web serving? If you are managing servers in Oslo or deploying for European clients, you don't have time for philosophy. You need throughput.

I recently audited a client's setup running a high-traffic Magento store targeting the Nordic market. They were suffering from massive lock contention during peak hours. The culprit wasn't just the database engine; it was the underlying virtualization. They were on a cheap, oversold OpenVZ container where the "guaranteed" RAM was a lie and disk I/O was fighting with 50 other neighbors.

Let's look at the state of the art as of mid-2011 and decide what runs on your metal.

MySQL 5.5: The Default Standard, Evolved

If you are running a standard LAMP stack (Linux, Apache, MySQL, PHP), MySQL is likely already there. With the release of MySQL 5.5 late last year, InnoDB became the default storage engine. This is critical. If you are still running MyISAM on a high-write production database, you deserve the table-level locking issues you are experiencing.

When to stick with MySQL:

• Read-Heavy Workloads: For simple SELECT queries, MySQL 5.5 is still incredibly fast.
• Replication Familiarity: Master-Slave replication is simple to set up, though asynchronous.
• CMS Compatibility: WordPress, Joomla, and Drupal expect it.

Optimization Tip: Stop using default configurations. In /etc/my.cnf, you must tune the buffer pool to utilize your RAM, or your disk I/O will kill you.

[mysqld]
# Allocate 70-80% of RAM if this is a dedicated DB server
innodb_buffer_pool_size = 4G
innodb_flush_log_at_trx_commit = 2  # Riskier for ACID, but faster for writes
innodb_file_per_table = 1

PostgreSQL 9.0: The Giant Wakes Up

For years, the argument against Postgres was "it's too slow" or "replication is a nightmare." With version 9.0 released last September, that argument is dead. The introduction of Hot Standby and Streaming Replication allows you to run read-only queries on slave servers easily. This brings Postgres to feature parity with MySQL's replication but with better data integrity.

When to switch to PostgreSQL:

• Complex Queries: If you are doing heavy JOINs across multiple tables, the Postgres query planner is superior.
• Data Integrity: Strict ACID compliance means you won't find silent data corruption.
• GIS Data: If your startup is doing anything with maps or location data in Norway, PostGIS is lightyears ahead of MySQL's spatial extensions.

The Config Check:

# postgresql.conf
shared_buffers = 2GB # significantly less than MySQL, relies on OS cache
work_mem = 16MB # Be careful, this is per connection!
effective_cache_size = 6GB

The Hidden Bottleneck: Virtualization & I/O

You can tune my.cnf all day, but if your underlying disk subsystem is thrashing, your latency will spike. This is where the choice of hosting provider becomes an architectural decision, not just a billing one.

Many budget VPS providers use OpenVZ or Virtuozzo. In these environments, you share a kernel. More importantly, the disk cache is often contended. If a neighbor on the same physical node decides to compile a kernel or run a backup, your database latency shoots up.

At CoolVDS, we rely strictly on KVM (Kernel-based Virtual Machine). This matters because:

1. RAM Isolation: When we allocate 4GB of RAM to your database, it is reserved for you. Linux manages its own memory pages.
2. I/O Scheduler: You can set your scheduler to deadline or noop inside your VM, which is ideal for our high-performance RAID-10 SAS arrays and the emerging SSD tier.
3. No Steal Time: We don't oversell CPU cores. Your database won't hang waiting for the hypervisor.

Pro Tip for Norwegian Ops: Keep your latency low. If your users are in Oslo or Bergen, routing traffic through a datacenter in Texas is negligence. CoolVDS infrastructure peers directly at NIX (Norwegian Internet Exchange), keeping round-trip times in the single digits. Plus, adhering to the Personopplysningsloven (Personal Data Act) is much easier when the bits physically stay in the country.

The Verdict

If you are building a brochure site or a standard blog, stick to MySQL 5.5. It’s fast, forgiving, and universal.

However, if you are building a custom application handling financial data, complex analytics, or geospatial routing, PostgreSQL 9.0 is the professional choice. Just remember: a robust database needs robust I/O. Don't choke your architecture on a shared-kernel container.

Need to benchmark the difference? Deploy a KVM instance on CoolVDS today and run pgbench or sysbench against your current host. The results will speak for themselves.