The Database Wars: Choosing Iron for Your Norwegian Infrastructure
April 20th changed everything. Oracle announced they are buying Sun Microsystems. If you are running a LAMP stack in Oslo or managing a dev team in Kyiv, you felt that tremor. The future of MySQL is suddenly... complicated.
For the last five years, the default answer has been MySQL. It’s the 'M' in LAMP. It reads fast, it's everywhere, and it's easy. But with the corporate shifts and the maturing of PostgreSQL 8.3, the "default" choice might be the wrong choice for your next deployment.
I've spent the last week migrating a high-traffic news portal off a crashing shared host onto a dedicated VPS. I've seen exactly where MySQL chokes and where PostgreSQL shines. Let's look at the hard data, ignoring the hype.
MySQL 5.1: The Speed Demon (With a Catch)
MySQL is built for speed, specifically read speed. If you are serving static pages or a simple blog, it flies. The setup is trivial. But here is the dirty secret: the default storage engine, MyISAM.
MyISAM uses table-level locking. This is a disaster for write-heavy applications.
The Scenario: You have a table with 500,000 rows. A user posts a comment. MyISAM locks the entire table to write that comment. Meanwhile, 50 readers trying to view the article are put in a queue. Latency spikes. Your load average hits 15.0. The server melts.
If you stick with MySQL, you must switch to InnoDB. It provides row-level locking and transactions (ACID compliance). It’s heavier on RAM, but it keeps your site alive during traffic spikes from VG or Digi.no.
Essential MySQL Optimization
Don't run the default my.cnf. It is optimized for 64MB RAM. On a modern CoolVDS slice, you need to crank this up:
[mysqld]
# Stop using MyISAM defaults
default-storage-engine = InnoDB
# The most critical setting for InnoDB performance
# Set to 70-80% of available RAM on a dedicated DB server
innodb_buffer_pool_size = 512M
# Prevent disk thrashing
innodb_flush_log_at_trx_commit = 2
PostgreSQL 8.3: The "Academic" Heavyweight
Years ago, we laughed at Postgres. It was slow, bloated, and academic. That is no longer true. Version 8.3 (released last year) introduced HOT (Heap-Only Tuples), which drastically reduced the I/O overhead for updates.
PostgreSQL is strict. It cares about your data integrity. If MySQL is a drag racer, Postgres is a tank. It won't let you insert invalid dates (like `0000-00-00`), and it handles complex joins significantly better than MySQL's query optimizer.
When to use Postgres:
- You handle financial data (ACID compliance is strictly enforced).
- You need complex geospatial queries (PostGIS is years ahead of MySQL Spatial).
- You fear the Oracle acquisition might stifle MySQL development.
Tuning postgresql.conf
Postgres is conservative out of the box. You need to tell it about your system resources in /etc/postgresql/8.3/main/postgresql.conf:
# Default is too low for modern VPS
shared_buffers = 128MB
# Helps the planner estimate costs (should be equal to free RAM)
effective_cache_size = 384MB
# Checkpoints are I/O intensive. Spread them out.
checkpoint_segments = 10
The Hardware Reality: I/O is King
You can tune my.cnf until your fingers bleed, but if your underlying disk subsystem is garbage, your database will be slow. Databases are I/O bound.
Most hosting providers in Norway oversell their disk arrays. They put 500 customers on a single 7.2k RPM SATA drive. When your neighbor runs a backup script, your database query latency jumps from 2ms to 200ms.
This is where architecture matters. At CoolVDS, we don't play the overselling game. We use RAID-10 SAS arrays (15,000 RPM). We are also experimenting with the new Intel X25-E Enterprise SSDs for custom high-performance tiers. The difference is night and day. With RAID-10, you get the read speed of the stripe and the redundancy of the mirror.
Local Compliance: Datatilsynet is Watching
Whether you choose MySQL or Postgres, remember where your data lives. Under the Personal Data Act (Personopplysningsloven), you are responsible for the security of your user data.
Hosting in the US (Safe Harbor or not) introduces latency and legal headaches. Keeping your database in a Norwegian datacenter ensures low latency to the NIX exchange in Oslo and simplifies compliance. A localized VPS means your data never leaves Norwegian jurisdiction unless you tell it to.
Verdict
If you are building a simple CMS or blog? MySQL 5.1 (with InnoDB) is still the pragmatic choice. It's what your developers know.
If you are building a complex application, an ERP system, or you are paranoid about Oracle's roadmap? PostgreSQL 8.3 is the superior technical product.
But software is only half the battle. Don't let disk wait times kill your application. Deploy your database on a platform that guarantees dedicated I/O throughput.
Need to test the difference? Spin up a CoolVDS instance in Oslo. We have template images for both MySQL 5.1 and Postgres 8.3 ready to go.