A prospective client asked last week why we were still using PostgreSQL for everything. Their current vendor, they explained, had moved to a modern graph database, a real-time data platform, and a microservices architecture. Shouldn't we be doing the same?
The honest answer: no. We choose boring technology on purpose, and we choose it for their benefit, not ours.
Boring technology—PostgreSQL, Python, nginx, Redis—has one overwhelming advantage: it works. Not "works most of the time" or "works if you configure it correctly." It works the same way today as it did five years ago, and it will work the same way five years from now.
Why boring wins
When a client calls with a production issue, we do not want to be debugging a database we adopted six months ago because it looked interesting on Hacker News. We want to be using a database that has been battle-tested by millions of deployments, documented exhaustively, and understood by every engineer we might hire.
Boring technology also compounds. Every hour we do not spend learning a new framework is an hour we can spend understanding the client's business logic, optimizing queries, or adding features that matter. Every system we do not have to rewrite when the new shiny thing turns out to have scaling problems is a system that keeps working while our competitors are firefighting.
When to choose exciting
We are not dogmatic. There are cases where new technology solves a problem that boring technology cannot. But the bar is high. The new technology has to be meaningfully better at the specific thing we need, not just better in theory.
We adopted LLM-based extraction for Clad because it solved a problem—understanding ambiguous contract language—that rules-based systems genuinely could not. We did not adopt it because it was trendy. We adopted it because it worked, we could measure that it worked, and we could explain to the client exactly why it was better than the alternative.
The PostgreSQL question
The client who asked about PostgreSQL was surprised to learn that it handles everything we throw at it. Multi-terabyte datasets, complex joins, full-text search, JSON queries, time-series data—all in one database, all with a query planner that has been optimized for thirty years.
Could we use a specialized database for each use case? Sure. Do we want to operate six different databases, each with its own failure modes, backup procedures, and monitoring requirements? Absolutely not.
We would rather have one database that works than six databases that are theoretically optimal.
— Marco