MySQL vs PostgreSQL: Choosing Your Weapon in the Post-Sun Era

It has been nine months since Oracle closed the acquisition of Sun Microsystems, and the tremors are still being felt in server rooms from Oslo to Bergen. For years, the decision was automatic: you install the LAMP stack, you use MySQL, and you move on. But with the uncertainty surrounding MySQL's future and the massive technical leap forward in the newly released PostgreSQL 9.0 (just last month), the landscape has shifted.

I have spent the last week migrating a high-traffic e-commerce client from a shared hosting environment to a dedicated KVM setup. During the load testing, we saw tables locking up harder than rush hour traffic on Ring 3. It forced us to re-evaluate the core of our stack. Here is the technical reality of choosing a database in late 2010.

The MySQL Reality: Speed vs. Reliability

MySQL is ubiquitous. It is the 'M' in LAMP. For 90% of read-heavy web applications—think WordPress blogs, Joomla sites, or simple forums—it is still the speed king. It is lightweight and developers know it.

However, the default storage engine, MyISAM, is a ticking time bomb for write-heavy applications. It uses table-level locking. If one user writes to the orders table, MySQL locks the entire table. Everyone else waits. On a busy site, this creates a queue that spikes your CPU load and kills user experience.

The Fix: If you stay with MySQL, you must switch to InnoDB. It supports row-level locking and transactions (ACID compliance). Check your /etc/mysql/my.cnf immediately:

[mysqld]
# If this isn't set, you are barely using your RAM
innodb_buffer_pool_size = 512M 

# Essential for data durability
innodb_flush_log_at_trx_commit = 1

# Switch default engine to InnoDB
default-storage-engine = InnoDB

Pro Tip: Don't blindly trust `top`. Install `htop` or use `vmstat 1` to watch the `wa` (IO wait) column. If your CPU is idle but `wa` is high, your database is choking on disk I/O, not processing power.

PostgreSQL 9.0: The New Heavyweight

PostgreSQL has always been the "academic" choice—strict, reliable, but historically harder to replicate. That changed in September with version 9.0. The introduction of Streaming Replication and Hot Standby is massive.

Previously, we had to rely on complex WAL (Write Ahead Log) file shipping to create a backup server. Now, you can have a readable slave server updated in near real-time. For mission-critical applications where data loss is unacceptable (financial records, customer data compliant with the Norwegian Personal Data Act), Postgres is becoming the superior choice.

It handles complex joins significantly better than MySQL. If your application requires nested queries or geospatial data (PostGIS), MySQL 5.1 simply cannot compete.

Performance Tuning Postgres

Postgres is conservative out of the box. It assumes it is running on a machine with 32MB of RAM. You need to edit postgresql.conf to tell it you have modern hardware:

# allocating 25% of RAM is a good starting point for shared_buffers
shared_buffers = 256MB 

# Effective cache size tells the optimizer how much memory the OS uses for caching
effective_cache_size = 768MB

# Checkpoints: increasing this reduces disk thrashing
checkpoint_segments = 32

The Infrastructure Bottleneck: Virtualization Matters

You can tune your configuration files all day, but if your underlying VPS is fighting for I/O resources, your database will crawl. This is the dirty secret of cheap hosting.

Many providers use OpenVZ or Virtuozzo to oversell resources. In those environments, you share the kernel with every other customer on the node. If a neighbor decides to compile a kernel or run a backup script, your database latency spikes.

At CoolVDS, we rely strictly on KVM (Kernel-based Virtual Machine). This provides true hardware virtualization. Your RAM is allocated, and your disk I/O is isolated. For databases, we utilize high-performance SAS 15k RPM RAID arrays or the emerging Enterprise SSDs for specific high-performance tiers.

Local Latency and Compliance

If your users are in Norway, hosting in Germany or the US adds 30-100ms of latency to every database handshake. If your PHP app makes 10 DB calls to generate a page, that adds up to a sluggish second of delay.

Furthermore, Datatilsynet (The Norwegian Data Protection Authority) is becoming increasingly strict regarding where personal data resides. Keeping your data on Norwegian soil, or at least within the EEA with strict safeguards, is not just about speed—it is about legal safety under the Personal Data Act of 2000.

Verdict: Which do you choose?

If you are running a standard WordPress site, stick with MySQL 5.1 (or look at the 5.5 Release Candidates). It is fast and simple. But if you are building a custom application requiring data integrity and complex logic, PostgreSQL 9.0 on a KVM slice is the professional route.

Ready to test your schema? Don't let shared hosting I/O wait kill your project. Deploy a KVM instance with CoolVDS in Oslo today. We offer a pre-configured LAMP stack or a clean slate for your custom Postgres compile.