The junior engineer wanted to use Kafka.
The system processed maybe 200 events per day. It had three users — all internal. The team was two people. But he'd just watched a conference talk about event-driven architecture and the diagrams were clean, and Kafka was what Netflix used, and if it was good enough for Netflix.
The senior engineer on the call listened patiently, then asked one question: "What problem does this solve that a Postgres table with a background worker doesn't?"
Silence.
That question — deceptively simple, slightly uncomfortable — is one of the most important questions in software engineering. And the engineers who ask it instinctively, without needing to think about it, are usually the most dangerous ones in the room.
The Shiny Object Has a Business Model
Every few months, the industry manufactures a new consensus. A new database paradigm. A new runtime. A new deployment philosophy. A new everything. The conference circuit talks about it. The hot takes multiply. Job postings start listing it. Engineers start feeling a vague anxiety that they're falling behind.
This is not entirely organic. There are companies, VCs, developer relations budgets, and marketing teams whose entire purpose is to make you feel like the thing you're currently using is inadequate. The shiny object has a business model. Excitement is the product.
None of this means the new thing is bad. Some of it is genuinely transformative. But the signal-to-noise ratio in the hype cycle is brutal, and engineers who haven't developed immunity to it make architectural decisions that look bold in a design doc and expensive on a production incident call at 2 a.m.
What "Boring" Actually Means
Boring technology isn't old technology. It isn't bad technology. It isn't a failure of imagination.
Boring technology is technology that has been in production long enough to show you all its failure modes. The bugs are known. The community is large. The StackOverflow answers exist. The runbooks are written. When something goes wrong — and something always goes wrong — you are not the first person to Google the error message.
PostgreSQL is boring. It is also one of the most reliable, capable, and battle-tested pieces of software ever written. It has handled write-heavy workloads, time-series data, full-text search, geospatial queries, and JSON documents for decades. Companies have tried to replace it with newer, shinier alternatives and quietly returned, tails between legs. PostgreSQL doesn't care. It just keeps running.
Redis is boring. Linux is boring. S3 is boring. nginx is boring. These are systems that have absorbed the collective operational knowledge of thousands of engineering teams running millions of production systems across every conceivable scale. That knowledge is baked in. You inherit it for free.
The new thing might be better. The boring thing is known. At most, known beats better.
The Hidden Cost of Novel
When you introduce a technology your team hasn't used in production before, you are not just making a technical decision. You are making a bet — and the stakes are denominated in things that don't show up in the architecture diagram.
Hiring becomes harder. Every non-standard technology in your stack is a filter on your candidate pool. Postgres engineers are everywhere. Engineers with deep operational experience in your chosen graph database from 2022 are not.
Debugging gets expensive. When a well-understood technology misbehaves, you pattern-match to known failure modes. When a novel one misbehaves, you're doing archaeology. The error messages are cryptic. The documentation is incomplete. The GitHub issues are open and unanswered.
Onboarding slows. A new engineer joining the team has to learn the domain and the custom infrastructure choices. Every deviation from the boring defaults is a tax on every future hire, every handoff, every 4 a.m. page from someone who didn't write the original code.
The upgrade path is unknown. Boring technology has a predictable maturity curve. You know how to migrate between major versions because thousands of teams have done it before you and written about it. Novel technology might break its own API twice before it reaches stability.
Dan McKinley coined the phrase "innovation tokens" — the idea that any engineering organization has a finite budget for novelty, and spending it on infrastructure that doesn't differentiate your product is almost always a bad trade. The question isn't "is this technology interesting?" It's "is this the right place to spend an innovation token?"
The Seniority Signal Nobody Talks About
There's an unofficial test for engineering seniority that never appears in job descriptions:
Can you walk into a design review, look at an architecture involving five novel technologies, and say — calmly, without apology — "I think we can do this with Postgres and a cron job"?
Because junior engineers reach for complexity to signal competence. They want the architecture to look impressive because the diagram is how they demonstrate they know things.
Senior engineers have already learned what complex architecture actually costs. They've been paged by it. They've onboarded new teammates into it. They've untangled it at 2 a.m. after someone else left the company. They have scar tissue where their enthusiasm used to be.
The transition from "how do I make this look smart?" to "how do I make this not my problem at 2 a.m.?" is one of the most important developmental moments in an engineering career. It's quiet when it happens. It doesn't come with a promotion announcement. But the engineers around you notice.
When Shiny Is Actually Right
Intellectual honesty requires this section.
Sometimes the boring option genuinely doesn't fit. If you're processing millions of events per second and ordering guarantees matter, yes — you probably need Kafka. If you have genuinely complex graph traversal requirements at scale, a graph database might be the right call. If your latency requirements are so tight that a general-purpose solution leaves real performance on the table, a specialized tool earns its complexity.
The test isn't "is this new?" The test is: does the capability this technology provides directly address a problem we actually have, and does that problem justify what we'll pay in operational complexity?
If the answer is yes, reach for the new thing with clear eyes and build the runbooks before you need them.
If the answer is "we might need this someday" — that's a Postgres table.
Write down the specific, measurable problem you expect the new technology to solve before you evaluate it. If you can't write it down in one sentence, you're probably solving a problem you don't have yet.
The Confidence at the Bottom of It
Here's the thing about boring technology that nobody says out loud: it takes confidence to choose it.
Choosing the exciting new thing feels safe. You're on trend. Nobody can criticize you for using what the industry is talking about. If it fails, you can blame the immaturity of the ecosystem. If it works, you look forward-thinking.
Choosing Postgres in 2026 is a statement. It says: I don't need novelty to do my job. I need results. It says you've thought about what you're actually solving and you've decided the boring answer is the right one. That's not laziness. That's judgment. And judgment is exactly what separates engineers who maintain systems from engineers who build systems worth maintaining.
The best code I've ever read was unremarkable. Obvious variable names. Straightforward control flow. No clever abstractions. Just a direct solution to a clear problem, written by someone who had absolutely nothing to prove.
The engineers worth learning from rarely need to impress you. The work does it quietly, in production, at scale, for years.