MySQL 5.5 vs. PostgreSQL 9.0: Surviving the Database Wars of 2010

The Oracle Elephant in the Server Room

It has been a turbulent year for systems administrators. Since Oracle closed its acquisition of Sun Microsystems earlier in 2010, a nervous energy has permeated the open-source community. Is MySQL still safe? Should we be looking at the forks like MariaDB? Meanwhile, PostgreSQL dropped version 9.0 in September, finally introducing built-in binary replication and hot standby—features we used to have to hack together with Slony or DRBD.

I’ve spent the last month migrating a high-traffic Norwegian e-commerce client from a crumbling shared host to a dedicated KVM setup. The bottleneck? Always the database. The decision of which engine to run is no longer just about preference; it’s about survival.

MySQL: The Speed Demon vs. The Locking Nightmare

MySQL is the engine that built the web. It's the 'M' in LAMP. But if you are still running default configurations in 2010, you are sitting on a time bomb. By default, many distributions still lean on the MyISAM storage engine. MyISAM is fast for reads, but it employs table-level locking.

Here is the scenario that wakes me up at 3 AM: A user writes a comment on your site. MyISAM locks the entire table. Meanwhile, 500 users trying to read that table are queued. Your load average spikes, Apache runs out of worker threads, and your site times out.

With the release of MySQL 5.5 (GA just this month), InnoDB becomes the default. InnoDB uses row-level locking and transactions (ACID). If you are deploying on CoolVDS today, your /etc/my.cnf needs to look like this immediately:

Using innodb_flush_log_at_trx_commit = 2 is a pragmatic choice for web apps where losing 1 second of transactions in a power failure is acceptable compared to the I/O penalty of strict syncing.

PostgreSQL 9.0: Finally Ready for the Masses?

Historically, PostgreSQL was viewed as the "academic" database—strictly correct, feature-rich, but slow and painful to scale. That changed this year. Version 9.0 is a revelation.

The killer feature is Streaming Replication. Before 9.0, we had to ship WAL (Write Ahead Log) files manually. Now, you can set up a read-replica in Norway while your master sits in Germany with minimal lag. For data integrity fanatics—especially if you are dealing with financial data subject to the Norwegian Accounting Act (Bokføringsloven)—PostgreSQL is the superior choice. It doesn't truncate data silently like MySQL sometimes does.

Pro Tip: If you are using PostgreSQL 9.0, enable hot_standby in your postgresql.conf. This allows you to run read-only queries against your backup server, offloading reporting tasks from your master node.

The Hardware Reality: I/O Wait is the Real Enemy

You can tune your config files until your fingers bleed, but physics is physics. Databases are I/O bound. Most budget VPS providers in Europe are still overselling spinning hard drives (SATA 7.2k RPM). When your neighbor on the same physical host starts a backup, your database latency skyrockets. This is 'Steal Time' in top, and it is the metric of doom.

This is why we architect CoolVDS differently. We use KVM (Kernel-based Virtual Machine) virtualization. Unlike OpenVZ, KVM provides true hardware isolation. We also prioritize high-performance SAS and early-generation SSD caching where possible. If you are targeting users in Oslo, you need the server physically close to NIX (Norwegian Internet Exchange) to keep latency low, but you also need disk throughput that can keep up with InnoDB's flushing.

Compliance and The Data Inspectorate

Operating in Norway means respecting the Personal Data Act (Personopplysningsloven). While MySQL vs. PostgreSQL is a technical choice, where that data lives is a legal one. Keeping user data within the EEA (European Economic Area) is critical to satisfy Datatilsynet requirements. Don't host your database in a US cloud if you can't guarantee Safe Harbor compliance.

The Verdict

• Choose MySQL (InnoDB) if: You are running CMS platforms like WordPress, Joomla, or Drupal, and you need raw read speed for simple queries.
• Choose PostgreSQL 9.0 if: You require complex joins, geospatial data (PostGIS is incredible), or strict transactional integrity for custom applications.

Whichever engine you choose, do not let slow disk I/O strangle your application. Database queries should be measured in milliseconds, not seconds.

Ready to test your schema performance? Deploy a KVM instance on CoolVDS today and experience true resource isolation.