Boring databases age better

Postgres in 2018 was already boring. In 2026 it is somehow more boring, and somehow more interesting. We start almost every backend with it, and we've never regretted that choice. Not once.

The flashy database of any given year almost never survives the next four. The graph DB era. The document DB era. The "serverless-first" era. Each came with promises about the queries you'd never have to write again, and each ended with someone — often us — painfully migrating data back to something that supports a JOIN.

What you give up by being boring: nothing important. JSON columns when you need them. Full-text search, when you need it. Listen/ notify for cheap pubsub. Pgvector when the AI hype eventually arrives at your codebase. Most of the "we should use X" arguments dissolve once you actually try the thing in Postgres first.

We have one client running on Postgres 9 from 2018, untouched. Migrating to 16 took a Saturday afternoon and a careful pg_dump/pg_restore. Our own studio database is the same. The boring choice paid for itself eight years ago and keeps paying.

The arcs above are the conversations we've had with clients over the past decade — graph in 2014, document in 2017, serverless in 2020, vector in 2024. Each came in as "we're thinking about migrating, what do you think?" The honest answer was almost always "Postgres can do that, would you like us to show you?" followed by a one-week proof. Three of those POCs landed in production. None of them required a new database.

The exceptions are honest. We've used Redis in production for years — different problem, complementary tool, never replaces Postgres. We've reached for ClickHouse twice when the analytic query was a hundred million rows wide and the latency target was tight. We'll pick up DuckDB next time the analytics side is single-tenant. Boring doesn't mean only one tool. It means starting from the tool that survives.

The Postgres-9-to-16 migration is worth a second mention because of how unremarkable it was. We took a backup, stood up a 16, restored, ran a smoke test, switched DNS. The hardest part was scheduling. The hardest part is always scheduling. That is the advertisement for boring databases — the hardest part is scheduling, not engineering.