← Back

The Case for Boring Technology

5 min read

Dan McKinley wrote Choose Boring Technology in 2015 and I think about it roughly once a week. The core argument: every company gets a limited number of innovation tokens, and you should spend them on your actual product, not on your infrastructure.

I want to add a corollary: boring technology is not the same as bad technology. PostgreSQL is boring. It's also extraordinarily good.

What "boring" actually means

Boring technology is technology where:

  • The failure modes are well-understood
  • Stack Overflow has answers to your questions
  • There are people you can hire who already know it
  • The bugs have been found and fixed over years of production use
  • You're not going to be the one discovering edge cases

When your database does something unexpected at 3 AM, you want to be searching a problem that ten thousand other people have already encountered and solved.

The hidden cost of interesting technology

Every new technology you adopt comes with costs that aren't visible at evaluation time:

Learning curve. Your team has to learn the failure modes, the operational quirks, the configuration footguns. For a complex system, that might mean months of ramp-up before you can trust it in production.

Operational burden. Who's on call for it? Who understands it well enough to debug production issues? If that person leaves, what happens? Everyone understands how to fix a PostgreSQL outage. How many people know how to use Oceanbase?

Integration. How does it talk to everything else in your stack? The answer is usually "with a custom adapter that someone has to write and maintain."

Ecosystem. How good are the libraries, the monitoring tools, the deployment scripts? For boring technology, these exist. For exciting technology, you might be writing them yourself.

I've watched teams adopt a new streaming platform because it looked great in a benchmark, only to spend six months rebuilding the tooling that PostgreSQL's ecosystem provides out of the box.

When to use something interesting

I'm not arguing that you should never adopt new technology, but that you should be honest about the cost. Use your innovation tokens when:

  • The problem genuinely can't be solved with existing tools
  • The new technology is so dramatically better that the transition cost is justified
  • You have the team and the time to absorb the learning curve

"It would be slightly faster" is not a good reason. "It would let us do something that's currently impossible" sometimes is!

My boring stack

For most services I build, the stack looks like this:

  • Database: PostgreSQL
  • Cache: Redis
  • Queue: Redis (yes, really — BRPOPLPUSH gets you surprisingly far)
  • Search: PostgreSQL full-text search (until it isn't enough, and it usually is)
  • Language: TypeScript or Go, depending on the domain
  • Deployment: Containers on managed infrastructure

This stack is boring, yes. It's also the stack that runs most of the software you use every day. There's a reason for that.

Boring is a compliment

When I call technology "boring," I mean it with admiration. Boring technology is battle-tested technology that has survived long enough to have its rough edges worn smooth. It's technology that lets you focus on your actual problem instead of fighting your tools.

The most productive engineering teams I've worked with are the ones that made peace with boring. They ship faster, sleep better, and spend their energy on the things that actually matter to their users.

Your users don't care what database you use. They care that the product works.