Dan McKinley wrote "Choose Boring Technology" in 2015. A decade later, it's the most ignored piece of engineering writing I know. Every architecture review I've sat in has the same pattern — someone wants to introduce a new database, a new queue, a new runtime, and the justification never contains an honest accounting of what it will cost to operate in three years.

Novel technology is not bad. It's expensive in ways that don't show up in a proof of concept. The case for boring technology is not "don't innovate." It's "innovate where it counts, and be ruthless about everything else."

Innovation tokens are real

McKinley's framing: every company has a limited number of innovation tokens. Spend one on a novel primary datastore, one on a novel language runtime, one on a novel deployment model — and you've blown your budget for interesting work that actually differentiates the product.

A reasonable budget for a mid-size engineering org: three innovation tokens, total. Everything else should be boring. That's not conservative; it's how you free up capacity for the work that actually moves the business.

The operational cost they didn't tell you about

A new piece of infrastructure isn't just the tool. It's:

  • The on-call burden. Someone has to carry the pager for it. If one person knows the failure modes, you have a single point of failure in human form.
  • The monitoring integration. Dashboards, alerts, runbooks. Six weeks of work most teams forget to plan for.
  • The upgrade path. Every three years, minimum, you're on a migration project. If the project is FoundationDB or CockroachDB, that migration is a non-trivial engineering program.
  • The security review. Every new tool is a new dependency graph, new CVE stream, new patch schedule.
  • The hiring. Can you hire ten more engineers who know Rust for your infra tier? For Java, yes. For Rust, maybe, and at a premium.
  • The integration with everything else. Your backup system supports Postgres natively and your new datastore via a script someone wrote.

The POC doesn't surface any of this. That's why POCs lie.

Boring is boring because it works

The list of technologies I'd call boring in 2026, in the sense of "proven, operationally understood, widely hired for":

  • Postgres for 95% of databases. Yes, including the ones you think need something else.
  • Redis for caching. Valkey if you're ideological about the license.
  • Linux, Ubuntu LTS or RHEL, for servers. Not Alpine in production unless you have a specific reason.
  • Nginx or HAProxy for load balancing.
  • Kafka for event streams. RabbitMQ for queues.
  • Terraform for IaC (OpenTofu if the licensing bothers you).
  • Python or Go or Java for services. Pick two, not six.
  • S3 for blob storage.

Most production systems worth running use some subset of this list. The boring stack has books written about it, Stack Overflow answers for every error message, mature client libraries in every language, and ten years of breach-informed hardening guides.

When boring isn't boring anymore

The twist: some boring technology has become dangerous because nobody loves it enough to operate it well. The classic examples in 2026:

An in-house Jenkins server nobody has upgraded since 2021. An MS SQL 2014 instance running on a Windows Server 2012 R2 VM. An on-prem Exchange no one wants to touch. ElasticSearch clusters still on 6.x because the upgrade is "scheduled."
  • Boring is not "old and neglected." Boring is "mature, maintained, and understood."
  • If your "boring" stack is out of support, it's not boring. It's a risk.
  • Migration off neglected boring tech is often the highest-value modernization project a team can do. It's also the least glamorous, which is why it doesn't get funded.

Picking fights worth picking

Where do you spend the innovation tokens? On the things that are genuinely your competitive edge:

  • The ML platform, if ML is your product.
  • The real-time pricing engine, if pricing is where you beat competitors.
  • The fraud detection pipeline, if fraud is existential.
  • A novel data model, if your product depends on solving a schema problem no one else has solved.

Not on: which Kubernetes ingress controller to use, which observability platform to buy, which language to write your glue code in, whether to adopt a new build tool. Those are boring-technology decisions. Pick the one most people use and move on.

The takeaway: The goal of infrastructure is not to be interesting. It's to disappear so the product can be interesting. Spend your innovation tokens on the handful of things that actually differentiate you. For everything else — pick the boring option, operate it well, and resist the constant pull to replace it with something that's currently getting attention. Boring compounds.