A team has roughly three innovation tokens; each “interesting” technology spends one — on operations, hiring, unknown failure modes. Boring ≠ bad: boring = the failure modes are known and already googled. Postgres, until proven otherwise, is not conservatism but economics.
The source is Dan McKinley’s essay and talk “Choose Boring Technology” (2015), written from his years at Etsy. Two arguments carry it. First, the capacity for novelty is limited: “about three” tokens is his illustrative number, not a measurement, and the point is that it is small and fixed. Second, a technology’s cost is mostly paid after adoption, in operations, and the total cost grows with the number of distinct technologies, not with how good each one is: every additional database needs backups, upgrades, monitoring, on-call knowledge and a person who understands its failure modes at 3 a.m. A tool that is better for one problem can be worse for the company when it is the only thing of its kind in the stack.
An example. A team needs a job queue, full-text search and a time series of metrics. Postgres covers all three acceptably for a long while — SELECT … FOR UPDATE SKIP LOCKED for the queue, built-in text search, a partitioned table for time series — with one backup story and one set of operational knowledge. Adding a broker, a search cluster and a TSDB is three tokens spent before the product has found its load profile. When one of them becomes a measured bottleneck, that is the moment to spend a token on it.
The checkable form. A new technology in the stack requires an ADR (20) answering “what essential complexity (40) does the boring option fail to handle?” plus a measurement (37), not a benchmark from a vendor’s blog. A token is spent according to the load profile, not a conference talk. Misuse: “boring” as a veto on anything new — the essay argues for spending tokens deliberately, not for never spending them — and boring options stretched past their limits at great cost.