The excitement you feel about a new database is not evidence it belongs in your stack. Most of the time it's the opposite signal.
Every team has a fixed budget for how much unfamiliar technology it can absorb at once. Dan McKinley named this budget years ago with a concept that stuck for a reason: innovation tokens. Three per company, roughly. Spend one on a new database, one on a new language, one on a new deploy architecture, and the budget's gone. Everything built after that rests on foundations the team barely understands. Debugging runs on instincts nobody has yet. The system ends up staffed by whoever happened to be in the room when the decision got made.
Boring does not mean bad. Postgres is boring. Cron is boring. A REST API is boring. All three are also excellent. A decade of production use has already found their failure modes and documented their edge cases. Ten thousand engineers already know how to operate them at 2am.
The failure modes are the actual product. When Postgres breaks, the fix is a known quantity. Searchable, probably solved on a mailing list from 2011. When a database that shipped eight months ago breaks in a way nobody's hit yet, the fix is you. Alone, reading source code at 2am. You become the temporary world expert in a problem you didn't choose.
That gap is what "boring" is actually buying: certainty.
By 2016, Stack Overflow was serving over 200 million HTTP requests a day on 9 primary web servers. A "monolith plus" setup: one core application handling nearly all Q&A traffic, with a couple of things deliberately split out, like a tag-matching service. David Fullerton, the company's VP of engineering, presented the model at QCon in 2015. Nick Craver, the engineer who ran it, documented the specifics on his own blog the following year: SQL Server as the single source of truth, Redis for caching, Elasticsearch for search. No NoSQL. No sprawl of independent services chasing every problem with its own database.
The industry consensus at the time said scale meant NoSQL and dozens of services. Stack Overflow scaled by getting extremely good at a boring stack. The real lesson: a team that deeply understands its boring tools can push them further than most people assume, and the resulting system stays debuggable by the whole team.
Here's the tell that gives away a bad technology decision before it's made: the pitch centers on the technology itself. "We should use Kafka" is a pitch about Kafka. "Our current queue drops messages under load and Kafka's replication solves that specific failure" is a pitch about the problem, which happens to route through Kafka. The first pitch spends a token on excitement. The second spends it on a gap that was actually costing something.
Ask what specific, current pain the new technology removes. If the honest answer is "nothing yet, but it's more scalable" or "the docs are nicer," that's excitement disguised as an engineering argument.
None of this argues for standing still forever. Systems outgrow their tools, and there's a real cost to riding MySQL past the point where it's the right shape for the problem. The three-token budget works as a forcing function. It makes you spend deliberately, on the one or two bets each year that actually move the business. Without it, tokens scatter across every tool that looked interesting in a conference talk.
Teams that ignore the budget don't fail from any single bad pick. They fail from accumulation. Five unfamiliar systems pile up, each reasonable on its own. Together they form a stack nobody on the team fully understands. Usually it's held together by the two engineers who set each piece up, right up until they leave for a different job.
Excitement is cheap and universal. Everyone gets excited by the same conference talks, the same trending GitHub repos, the same tool that promises to make everything faster. That's exactly why it's a bad filter. It selects for what's popular this quarter.
Pick the technology that's already boring to someone else. Save the excitement for the problem only you have.