In Praise of Boring Databases
Every project I have ever shipped ends up on Postgres. The projects that started on the exciting choice ended up on Postgres too — usually at 2 a.m.
The pattern
A new workload appears. Someone says the relational model does not fit it. We adopt a purpose-built store. It is genuinely better at that one thing. Then:
- The product needs a join.
- The product needs a transaction.
- The product needs "just query it like a table."
The purpose-built store was never wrong — it was early. The workload it was built for shows up later, at a scale where migration hurts.
What boring buys you
- One mental model. Indexes, constraints, and a query language I can dream in.
- An ecosystem of tools. Backup, replication, observability, and every language's driver — all mature.
- Hiring and onboarding. Anyone can help you with Postgres at 2 a.m.
When boring is wrong
Genuinely: massive write-throughput key-value access, graph traversals, full-text at absurd scale, queues at millions of messages per second. Use the right tool — after measuring, and ideally after the boring option has measurably failed.
The best database is the one that will still be fine in ten years, even if you never think about it again.