The Eternal Flame War: Dolphin vs. Elephant
If I had a krone for every time a developer asked me, "Which database is faster?", I could retire to a cabin in Geilo. It is the wrong question. In the systems world—especially here in the Nordics where we value reliability as much as speed—the right question is: Which database will not wake me up at 3 AM with a corrupted index?
We are currently seeing a shift. With the recent release of MySQL 5.5 making InnoDB the default engine, and PostgreSQL 9.0 finally bringing usable replication to the table, the gap is closing. But they are beasts of different burdens. I have spent the last decade managing clusters from Oslo to Frankfurt, and here is the brutal truth about running these on virtual private servers.
MySQL: The Speed Demon (With a Catch)
MySQL is ubiquitous. It is the 'M' in LAMP. For years, we relied on the MyISAM storage engine because it was fast for read-heavy workloads (like WordPress blogs or vBulletin forums). But MyISAM has a fatal flaw: table-level locking. If you write to a row, the whole table locks. On a high-traffic site, this creates a queue longer than the Vinmonopolet before Easter.
MySQL 5.5 changes the game by defaulting to InnoDB. This brings row-level locking and proper ACID transactions. However, default configurations are often terrible.
Optimization Tip: If you are running MySQL 5.5 on a CoolVDS instance with 4GB RAM, do not leave `my.cnf` at default. You must tune the buffer pool to cache data in memory rather than hitting the disk.
[mysqld]
innodb_buffer_pool_size = 2G
innodb_flush_log_at_trx_commit = 1
# Set to 2 if you can tolerate 1 second of data loss for 10x speed.Use MySQL if you need read scalability and are working with developers who treat SQL like a simple key-value store. It works. It is fast. But watch your replication lag.
PostgreSQL: The Fortress of Data Integrity
PostgreSQL has always been the "academic" choice, but with version 9.0, it has become a production powerhouse. It handles complex queries, JOINS, and sub-selects significantly better than MySQL. If your application involves financial data or complex logic, do not gamble with MySQL's loose type constraints. Postgres is strict. It will reject your bad data, and you will thank it later.
The killer feature in 2011 is Streaming Replication. In the past, we had to rely on cumbersome trigger-based solutions like Slony. Now, setting up a Hot Standby is built-in.
Optimization Tip: Postgres loves RAM. On a Linux VPS, you need to adjust kernel shared memory limits (shmmax/shmall) in `/etc/sysctl.conf` before Postgres can even utilize your server's memory effectively.
# /etc/sysctl.conf
kernel.shmmax = 2147483648
# Apply with sysctl -pPro Tip: Unlike MySQL, PostgreSQL spins up a new process for every connection. If you have a high-concurrency app (like a busy Magento store), you absolutely need a connection pooler like pgBouncer. Without it, the context switching will kill your CPU.
The I/O Bottleneck: Why Hardware Matters
You can tune `my.cnf` or `postgresql.conf` for weeks, but if your underlying storage is slow, your database is slow. This is physics.
Most VPS providers in Europe are still overselling spinning SATA disks. In a database environment, IOPS (Input/Output Operations Per Second) are king. When a query requires a disk seek, your CPU sits idle, waiting. This is 'iowait', and it is the silent killer of server performance.
This is why at CoolVDS, we are aggressive about adopting Enterprise SSD storage. The random read/write performance of SSDs compared to traditional 15k RPM SAS drives is not just an upgrade; it is a paradigm shift. Queries that took 200ms on spinning rust take 2ms on our SSD arrays.
Data Sovereignty and The Norwegian Context
We are operating under the Personopplysningsloven (Personal Data Act) and EU Directive 95/46/EC. If you are hosting customer data for Norwegian businesses, you need to know where that physical drive sits. Hosting in the US under the Patriot Act is becoming a legal headache for many CTOs in Oslo.
Latency is the other factor. If your users are in Norway, routing traffic through a datacenter in Texas adds 150ms of latency to every database handshake. Hosting locally in Scandinavia ensures you stay connected to the NIX (Norwegian Internet Exchange) with sub-10ms ping times. Speed is a feature.
Verdict: Which One to Deploy?
| Feature | MySQL 5.5 | PostgreSQL 9.0 |
|---|---|---|
| Best Use Case | Web apps, CMS, simple reads | Complex data, Financial, GIS |
| Replication | Master-Slave (Async/Semi-sync) | Streaming Replication (Hot Standby) |
| Storage Engine | Pluggable (InnoDB, MyISAM) | Unified (MVCC) |
| License | GPL (Oracle owned) | BSD (Community) |
If you are building a standard web application and need raw read speed, MySQL on a solid SSD VPS is unbeatable. If you are building an enterprise application where data integrity is paramount, PostgreSQL is the professional choice.
Whatever you choose, do not let your hard work be bottlenecked by cheap, oversold disk I/O. Databases live and die by the disk.
Ready to test the difference? Spin up a CoolVDS SSD instance today and benchmark your queries on real hardware. Stop waiting for iowait.