The Case for Boring Technology

A few years ago, a senior engineer on my team proposed replacing our PostgreSQL database with a trendy new distributed database. His pitch was compelling: better horizontal scaling, built-in sharding, and native support for our most common query patterns.

I asked one question: "How many production incidents have we had related to PostgreSQL scaling?"

The answer was zero. We were processing millions of transactions and PostgreSQL was handling it comfortably.

We kept PostgreSQL. And I got to have one of my favorite conversations with the team about the value of boring technology.

The Innovation Token Budget

Dan McKinley's concept of "innovation tokens" is one of the most useful mental models in engineering leadership. Every organization has a limited number of innovation tokens — things they can do that are new, unproven, or cutting-edge. Use them wisely.

If your product is an innovative healthcare platform, spend your tokens on the healthcare innovation. Use boring, proven technology for everything else — databases, message queues, deployment, monitoring.

When you spend innovation tokens on infrastructure, you're taking risk away from the parts of the system that actually differentiate your business.

What Makes Technology "Boring"

Boring technology isn't bad technology. It's technology that:

• Has been in production for years across many organizations
• Has well-understood failure modes — you know what can go wrong and how to fix it
• Has extensive documentation and community support — when you hit a problem at 2 AM, someone else has already solved it
• Has a large pool of engineers who know it — you can hire for it without training from scratch

PostgreSQL, Redis, RabbitMQ, Linux, Nginx — these are boring in the best possible way. They won't trend on Hacker News, but they'll run your production systems for years without drama.

The Cost of Excitement

Exciting technology has hidden costs that rarely appear in the evaluation:

Learning curve. Your team needs to develop expertise from scratch. This takes months and costs real productivity.

Unknown failure modes. You'll discover how the technology breaks in production, the hard way, because fewer organizations have battle-tested it.

Limited community knowledge. When you search for an error message, you find a GitHub issue from 3 months ago with no response.

Migration complexity. If the technology doesn't work out, migrating away is expensive. You've now built an entire system around something that might not survive.

Hiring friction. Finding engineers with experience in niche technology is harder and more expensive.

When to Use Exciting Technology

I'm not a Luddite. There are legitimate reasons to adopt new technology:

The boring option genuinely can't solve the problem. If you need real-time streaming of millions of events per second, PostgreSQL's LISTEN/NOTIFY isn't going to cut it. That's a valid use of an innovation token.

The team has deep expertise. If your team has production experience with the new technology from previous roles, the risk is significantly lower.

The technology has a clear, proven migration path. Can you adopt it incrementally? Can you run it alongside the existing solution? Can you roll back if it doesn't work?

The benefits are overwhelming and measurable. Not "it might be faster" but "we've benchmarked it and it's 10x faster for our specific workload."

My Decision Framework

When evaluating technology choices, I ask:

1. What problem are we solving?
2. Can a boring solution solve it?
3. If not, what's the simplest solution that can?
4. What's the operational cost of running this in production?
5. Can we hire engineers who know this?
6. What's our exit strategy if it doesn't work out?

Most of the time, the boring solution wins. And that's a good thing. Boring technology lets you focus your energy on the problems that actually matter to your business.

Save your excitement for the product. Let the infrastructure be boring.