Every few years a new database arrives with a better story than the last one. Faster, more scalable, more flexible, built for the cloud, built for AI. Some of them are excellent. Most teams should still start with PostgreSQL, and many should finish with it too.
That is not a lack of ambition. It is an argument about where a young product spends its limited attention.
What boring means
A boring database is one whose behaviour is well understood. Its failure modes are documented. Its tools, hosting options, backup methods and monitoring are mature. When something goes wrong at three in the morning, a search finds the answer, because thousands of people have been there before.
PostgreSQL, MySQL and their relatives qualify. They have decades of use behind them. They are not exciting, and that is the point: nobody on your team should be excited by their database during an outage.
The real price of novelty
Every unusual technology in your stack charges a tax, and the tax is paid in attention.
Someone must learn its quirks. Someone must work out how to back it up and, more importantly, how to restore it. Someone must understand how it behaves under load, what consistency it actually offers and what happens during a network partition. Hiring becomes harder because fewer people know it. Tooling is thinner. Documentation may be incomplete or out of date.
A new database may well be better at one thing. But you adopt all of it, including the parts that are merely different. Early in a company's life, the scarce resource is not query speed. It is the time of the few engineers who have to keep everything running while also building the product.
Boring is more capable than its reputation
A common reason for reaching for something specialised is a belief that a relational database cannot do the job. Often it can.
- Documents. PostgreSQL has a JSON type,
jsonb, that can be indexed and queried. Teams that wanted flexible schemas often discover they can have a relational core and a flexible column in the same system. - Search. Built in full text search handles many needs before a dedicated search engine is justified.
- Queues. A table with careful locking can serve as a job queue for moderate volumes. Row level locking features such as
FOR UPDATE SKIP LOCKEDexist for exactly this pattern. - Time series and geospatial work. Extensions extend the same engine into these areas.
- Transactions. This is the big one. Being able to change several related records atomically, with the database enforcing constraints, removes whole classes of bugs that otherwise land in application code.
Here is a small example of the queue pattern, to show how ordinary it is:
SELECT id, payload
FROM jobs
WHERE status = 'pending'
ORDER BY created_at
LIMIT 10
FOR UPDATE SKIP LOCKED;It will not suit every workload, but for a lot of products it removes a whole separate system.
Operations deserve a mention of their own. A mature database has well worn answers to the questions that decide whether you sleep at night. Point in time recovery lets you restore to just before a bad deployment. Streaming replication gives you a standby. Managed hosting from the large cloud providers handles patching and backups, and a competent engineer can learn the essentials in days. Compare that with a young system where the recovery procedure is a forum thread from last month.
Schema discipline is a quiet advantage too. A relational schema forces you to decide what your data is. Constraints, foreign keys and types catch mistakes at write time, rather than letting them surface as odd behaviour months later. Teams that skip this often rebuild it, badly, in application code.
Migrations are easier to reason about as well. Changing a column in a database you understand is a known procedure with known risks.
Fewer systems, fewer problems
Each additional data store is another thing to secure, back up, monitor, upgrade and keep consistent with the others. When the same fact lives in two systems, you now have a synchronisation problem, and synchronisation bugs are some of the hardest to diagnose.
One well run database gives you one source of truth, one backup story, one place to enforce rules about money, identity and permissions. For software that handles financial records or patient data, that simplicity is not a nicety. It is part of being able to explain to an auditor what is true.
When boring stops being enough
This is not a claim that specialised databases are pointless. They exist because real workloads outgrow general tools.
You may genuinely need something different when your data volume or write rate is beyond what a single well tuned relational setup can handle, when your access pattern is unusual in a way the engine cannot model, such as deep graph traversal at scale, or when latency requirements demand an in memory store. Analytical workloads over very large datasets are often better served by a columnar warehouse than by the database running your application.
The crucial point is sequence. Reach for the specialised tool when you have measured a problem the general one cannot solve, not when you have imagined one. Premature scale is an expensive hobby.
A final practical point: boring does not mean neglected. Run the database well. Index for your real queries, watch slow query logs, test restores on a schedule and keep it upgraded. Most complaints that a relational database cannot scale turn out to be complaints about a missing index or an untested query.
How to decide
Before adding a data store, ask these questions:
- What specific requirement does this meet that our current database cannot?
- Have we measured it, or are we guessing?
- Who on the team can operate it, restore it and debug it at night?
- What happens to consistency between this and our main database?
If those have good answers, go ahead. If the honest answers are vague, the reason is probably fashion.
A closing thought
Choose the database that lets you stop thinking about the database. Spend the saved attention on the part of your product that customers actually notice, and revisit the choice when real numbers, not forecasts, tell you to.