In praise of boring infrastructure

01The invoice arrives in year three

Every technology choice generates two invoices. The first covers construction; it arrives immediately and gets estimated in sprints. The second covers operation; it arrives quietly over years, as on-call load, upgrade debt, and the salary of the one engineer who understands the thing. In our engagements the second invoice is the one that hurts, and it is rarely the one that was priced.

In 2023 Amazon's Prime Video team published a rare line item from that second invoice. Their audio and video quality monitoring service, built on AWS Step Functions orchestrating Lambda workers with S3 as intermediate frame storage, hit a hard scaling limit at around 5 percent of expected load. Step Functions bills per state transition, the service performed multiple transitions for every second of monitored stream, and the volume of Tier-1 calls to S3 was expensive on its own. The team collapsed the distributed design into a single process that passes frames in memory, deployed it on ECS, and reported infrastructure cost down more than 90 percent alongside better scaling headroom.^[1] The post has since been removed from the Prime Video blog, so we cite the archived copy. Adrian Cockcroft's reading of the episode belongs next to the headline: he called it “clearly a microservice refactoring step,” a normal consolidation once the load and cost curves are known, not a repudiation of serverless.^[2] Both readings agree on the part that matters here: the boring shape was an order of magnitude cheaper to operate.

Segment documented the same curve from the inside. At peak they ran more than 140 per-destination microservices, each with its own queue and autoscaling profile, and reported that “with our microservice architecture, our operational overhead increased linearly with each added destination.” Consolidating into a single service collapsed roughly 120 distinct shared-library versions to one. The team then shipped 46 improvements to those libraries in the single year after consolidation, against 32 across the entire microservices era, and integration test runs fell from about an hour to milliseconds.^[3]

Even the flagship cloud-native project reached the same conclusion about itself. In 2020 Istio merged Pilot, Galley, Citadel, and the sidecar injector into a single binary, istiod, because operators never scaled or versioned the control-plane components independently, so the microservice split was paying costs without collecting benefits. Fewer components, the project wrote, means less cross-component environmental debugging.^[4] None of these teams were incompetent. The architecture itself was the recurring cost.

02What the evidence rewards

If novelty made teams fast, it would show up in the delivery research. It does not. The Accelerate program, the largest public study of software delivery performance, found that a loosely coupled, well-encapsulated architecture was among the strongest predictors of delivery performance, ahead of most tooling investments, and that the type of system under construction (greenfield, packaged software, even mainframe) had essentially no effect once architectural characteristics were controlled for.^[5] Read the capability catalog end to end and you will not find “adopt newer technology” anywhere in it. What the data rewards is coupling discipline, deployment practice, and culture, all of which are available on a ten-year-old stack.

Existence proofs carry more weight with us than survey coefficients, and the best one is documented by Dan Luu: Wave, a mobile-money company valued at $1.7 billion, runs on a Python monolith backed by PostgreSQL, operated by roughly 70 engineers. Luu describes the core, fairly and admiringly, as “a CRUD app that adds and subtracts numbers.”^[6] Wave's complexity budget goes where its business is genuinely hard, telecom integrations and data-residency deployments in its African markets, not into its web stack.

Boring choices are also hiring choices. In the 2025 Stack Overflow survey, PostgreSQL was the most used database outright: 55.6 percent of all respondents and 58.2 percent of professional developers, with MySQL second at 40.5 percent.^[7] The boring default is the tool the median engineer you will ever interview already operates. Every exotic component in the stack shrinks the pool of people who can carry its pager, and it shrinks it most at 3 a.m.

03Tokens and Lindy

Dan McKinley gave this discipline its accounting system in 2015: “every company gets about three innovation tokens.” The supply is fixed for a long while, and every novel component costs one.^[8] His definition of boring has nothing to do with quality. What mature technology offers is that “the capabilities of these things are well understood. But more importantly, their failure modes are well understood.” New technology fails in ways nobody has met yet, which is why “the long-term costs of keeping a system working reliably vastly exceed any inconveniences you encounter while building it.” His evidence was Etsy's activity feed, built on the Memcached the company already operated. Attention turned elsewhere for years, and the feature scaled roughly twentyfold with nobody watching it, because it rode the shared platform the whole company was already maintaining.^[8]

Technology for its own sake is snake oil.

That is McKinley again, and it names the failure of taste this note argues against.^[8] There is also a name for why the old tools keep winning. Lindy's Law began as Albert Goldman's 1964 observation about comedians' careers, was formalized by Mandelbrot, and was named by Taleb in Antifragile: “If a book has been in print for forty years, I can expect it to be in print for another forty years.”^[9] For nonperishables, and technologies are nonperishables, expected remaining life grows with age, because survival is itself evidence of fitness. Postgres, in continuous development since its Berkeley origins in the 1980s, is the everyday case. SQLite is the extreme one: its developers publish an intent to support it “through the year 2050,” its file format is bit-for-bit identical across 32-bit, 64-bit, big-endian, and little-endian platforms, and the US Library of Congress lists it as a recommended storage format for digital preservation.^[10]

Notice that none of this makes conference keynotes. That is the tell. The systems that survive a decade are the ones nobody talks about, and the silence is not neglect. It is the sound of software that works.

04The stack, with cliffs marked

Our default stack is one relational database carried as far as it will honestly go. Stephan Schmidt's “Just Use Postgres for Everything” catalogs how far that is: caching in UNLOGGED tables, job queues with FOR UPDATE SKIP LOCKED, documents in JSONB, native full-text search, vectors with pgvector, geospatial with PostGIS, scheduled work with pg_cron. His warning is the one we repeat in architecture reviews: “We have invited complexity through the door. But it will not leave as easily.”^[11]

Advocacy that hides the cliffs discredits the thesis, so we mark them. The skill is not “never leave Postgres.” The skill is knowing where the edge is before arriving at speed.

Two of those cliffs deserve the longer story. Recall.ai used LISTEN/NOTIFY for change signaling until, at tens of thousands of simultaneous writers, they found that NOTIFY at commit takes a lock that is global to the entire database, serializing every committing writer. During their March 2025 incidents, more than 200 processes queued behind a single lock holder while CPU and I/O collapsed. They moved the fanout into the application layer in about a day, and the underlying behavior was later addressed in a Postgres core commit.^[12] Note the exit price: one day, because everything around the failure was boring.

GitLab outgrew database-backed search at GitLab.com scale and runs advanced search on Elasticsearch. The architecture note is the part worth stealing: Elasticsearch is a secondary data store, and everything in it can be derived again from PostgreSQL and Gitaly.^[13] The specialized system enters as a rebuildable index, never as a second source of truth. That is the safe shape for anything that graduates out of the boring stack, and it keeps the exit cheap in both directions.

05How we spend a token

McKinley's talk contains the procedure, and we have run it enough times to trust it.^[8] The rule above all of it: a boring default is abandoned when it is measured to fail, never when it is predicted to. Here is the version we use.

1. Write the problem down without naming any technology. If a product name appears in the problem statement, you are reading an advertisement.
2. Attempt a solution with what you already operate, and write down every workaround it requires. That list, in writing, is the true price of staying boring, and now it can be compared against something.
3. Price the challenger's whole life, not its demo: the on-call rotation, the upgrade cadence, the security patching, the backup and restore drills, and the second engineer who must learn it before the first one resigns.
4. If the challenger still wins, confirm a token is available. The budget is about three, and it replenishes slowly.^[8]
5. Pilot on one bounded workload with a small blast radius, a stated success metric, and a dated decision point. A pilot without an end date is an adoption.
6. Decide as an organization, not as an individual. A technology one person brought in is a liability with that person's name on it, and it leaves when they do.
7. Commit in writing to killing whatever the new system replaces. Two systems doing one job is worse than either alone, and half-finished migrations are how a company ends up operating both forever.
8. Where possible, admit the newcomer in the GitLab shape: a derived store, rebuildable from the boring source of truth, deletable without losing data.^[13]

Steps 2 and 7 do most of the work. Step 2 converts a vague appetite for better tools into a priced list of annoyances, which is usually shorter than anyone expected. Step 7 is the difference between an architecture and a sediment.

06Where boring is wrong

Three exceptions keep this position from hardening into dogma.

The first is the differentiator. Tokens exist to be spent, and the correct place is the thing your business does that competitors cannot. A company whose product is a database should be inventing database technology. A team whose core loop depends on a capability the boring stack measurably cannot express has found what its tokens are for. Saving tokens on infrastructure is precisely what funds spending them on the product.

The second: boring is a property of variance, not of architecture diagrams. Monzo, a licensed bank, operates roughly 2,800 microservices and runs fleet-wide migrations with a single central team, which works because everything is uniform: one language, one monorepo, one deployment path.^[14] Two thousand identical services are operationally duller than five artisanal ones. The delivery research prices coupling and consistency, not service count.^[5]

The third: the boring list moves. Kubernetes cost a token a decade ago; today it is well along the same passage MySQL and Rails made before it, from exciting to load-bearing to assumed. Boring was never a blessed list of logos. It is a test, re-run every few years: age, adoption density, documented failure modes, and depth of the hiring pool.

Our closing position is the thesis stated plainly. Choose boring technology by default. Keep the source of truth in the oldest store that honestly fits. Admit specialized systems as derived indexes with written exit plans. Spend innovation tokens only where the business differentiates, and write down what each one bought. The systems that survive a decade are the ones nobody talks about, and when a system we built is still running quietly in year ten, absent from incident channels and conference stages alike, that silence is the deliverable.