The Database Wars Have Changed
If you asked me two years ago which database to use for a standard web application, I would have said MySQL without blinking. It was the 'M' in LAMP, it was everywhere, and it was fast enough. But it's late 2010. The landscape has shifted under our feet.
Oracle has acquired Sun Microsystems. For those of us managing critical infrastructure in Oslo and throughout the Nordics, this introduces a layer of uncertainty regarding the future of the open-source MySQL GPL license. Meanwhile, the PostgreSQL Global Development Group just dropped PostgreSQL 9.0 in September, finally bringing native streaming replication to the table.
I've spent the last month migrating a high-traffic e-commerce cluster from a legacy dedicated server to a virtualized environment. The bottleneck is rarely CPU anymore—it's disk I/O and architectural limits. Here is the raw truth about choosing your relational engine today.
MySQL 5.1/5.5: The Speed Demon with Baggage
MySQL is still the read-heavy champion. For simple SELECT queries on a blog or a CMS like WordPress or Joomla, it screams. However, the default storage engine history is messy. Many older setups still default to MyISAM, which uses table-level locking. If you have a site with heavy writes, MyISAM will queue your requests until the server chokes.
We are now pushing InnoDB for everything. It offers row-level locking and ACID compliance (Atomicity, Consistency, Isolation, Durability). If you stick with MySQL, you must ensure you are tuning for InnoDB, or you are asking for data corruption during a power failure.
# /etc/my.cnf optimization for 4GB RAM VPS
[mysqld]
default-storage-engine = InnoDB
innodb_buffer_pool_size = 2G
innodb_flush_log_at_trx_commit = 1
# Set to 2 if you can tolerate 1 sec data loss for speedPostgreSQL 9.0: The New Heavyweight
PostgreSQL has always been the "academic" choice—rock solid, strictly compliant, but historically painful to replicate. That ended with version 9.0. We now have Hot Standby and Streaming Replication out of the box.
This means we can finally set up a master-slave architecture where the slave is readable. For a complex application requiring complex joins, foreign keys, and strict data integrity (think banking or enterprise ERPs in the Norwegian market), Postgres is currently superior. It handles concurrency better than MySQL because it doesn't suffer from the same locking contention issues under massive load.
The I/O Bottleneck: Why Your Host Matters
You can tune sysctl.conf until you are blue in the face, but databases are fundamentally bound by Disk I/O. In a shared hosting environment, or on a VPS oversold by budget providers, your database is fighting for disk access with hundreds of other neighbors. We call this the "Noisy Neighbor" effect.
When running benchmarks using `pgbench` or `sysbench`, we see latency spikes on standard 7.2k RPM SATA drives. This is why for serious database workloads, we only deploy on CoolVDS instances backed by Enterprise SSDs. The random read/write speeds of Solid State Drives are not just a luxury anymore; they are a requirement if you want to avoid I/O wait times dragging down your load averages.
Pro Tip: Linux treats memory used for disk caching as "free" memory. Don't panic if `top` shows high memory usage. However, ensure your swappiness is low to prevent the kernel from swapping your database process to disk.sysctl vm.swappiness=10
Data Sovereignty and The Personal Data Act
Operating in Norway brings specific legal requirements under the Personopplysningsloven (Personal Data Act). While the Safe Harbor framework allows data transfer to the US, many Norwegian organizations are rightly skeptical about where their data physically resides.
Latency is the other factor. If your customer base is in Oslo, Bergen, or Trondheim, hosting your database in a datacenter in Texas adds 100-150ms of latency to every round trip. For a complex application executing 50 queries per page load, that adds seconds to your load time. Keeping data on local infrastructure, like CoolVDS's Oslo nodes, ensures both compliance with Datatilsynet guidelines and sub-10ms response times.
Final Verdict
- Choose MySQL (InnoDB) if: You are running a read-heavy CMS (WordPress/Drupal), you need widespread developer familiarity, or you are migrating a legacy PHP application.
- Choose PostgreSQL 9.0 if: You value data integrity above all else, you need complex queries/GIS data, or you need a robust master-slave replica setup for high availability.
Whichever engine you choose, do not cripple it with slow spinning platters. Database performance is 80% RAM/Disk speed and 20% configuration. Spin up a test instance on CoolVDS today, benchmark your I/O, and stop letting latency kill your user experience.