The case for boring infrastructure under interesting AI
Postgres, Redis, Temporal, Terraform. Why we pick technology that will be running in five years over the framework trending this quarter.
TLDR
Postgres, Redis, Temporal, Terraform. Why we pick technology that will be running in five years over the framework trending this quarter.
- Postgres, Redis, Temporal, Terraform. Why we pick technology that will be running in five years over the framework trending this quarter.
The temptation
A new database hits 50,000 GitHub stars. A new orchestration framework promises to eliminate the operational overhead of Kubernetes. A new edge runtime claims to reduce global p99 latency by 60%. The Hacker News thread is full of engineers reporting great early results.
Six months later: the database has a breaking change in its 0.x releases that affects your primary query pattern. The orchestration framework's documentation hasn't caught up with the API surface. The edge runtime has a CPU time limit that conflicts with one of your longer-running jobs.
We've lived through enough of these cycles to have a firm rule: boring infrastructure, interesting product.
What boring means
Boring doesn't mean outdated. Postgres is boring and Postgres 16 has features — logical replication improvements, parallel query enhancements, better JSON operators — that are genuinely useful. Boring means the infrastructure has been in production at serious scale long enough that its failure modes are well-documented, its community is large enough that your specific problem has been solved before, and its operational model is stable enough that your team can become genuinely expert in it.
Our default stack for production systems: Postgres for relational data, Redis for caching and pub/sub, S3 for object storage, Terraform for infrastructure-as-code, Kubernetes or ECS for container orchestration depending on team familiarity, Temporal for durable workflow execution.
None of these were the most exciting choice in the year they were adopted. All of them will be running reliably in five years. That's the criterion.
The AI exception that isn't
AI systems seem like they should be the exception to the boring infrastructure rule. The tooling is changing fast. New vector databases appear weekly. New LLM orchestration frameworks ship daily. You need to move quickly to stay competitive.
We've found the opposite is true. The AI layer — the models, the prompts, the retrieval mechanisms — moves fast enough that you need your infrastructure to be rock-solid and predictable under it. If your vector database is in beta and your workflow orchestration is a 0.4.x release, you are debugging three layers of instability simultaneously when something goes wrong.
Our practice: use boring infrastructure for the data and execution layers, and confine the fast-moving AI tooling to well-defined interfaces. LLM providers are abstracted behind a provider interface so you can swap models without touching orchestration code. Retrieval is behind a search interface so you can swap backends. The boring infrastructure doesn't know it's running an AI product.
The cost of interesting choices
The real cost of an interesting infrastructure choice is not the initial integration time. It's the maintenance tax over the lifetime of the system.
A team that chose an innovative job queue library in 2022 now owns a significant internal fork of that library because the upstream project shifted direction. The initial choice saved two days of integration time and has since cost six months of maintenance work.
Every infrastructure choice that deviates from your team's established expertise adds a maintenance tax. That tax compounds. A system with three novel infrastructure choices has a maintenance surface that's disproportionately larger than three times the cost of one novel choice, because the interactions between unfamiliar systems produce failure modes that are harder to diagnose than failures in any single layer.
When to break the rule
There are legitimate reasons to use non-boring infrastructure. You're building a real-time collaborative editor and you need a CRDT-native data store. Your use case genuinely requires a graph database and Postgres graph extensions won't cover it. Your team has deep expertise in a non-standard stack that is nonetheless well-understood within that team.
The question is whether you're breaking the rule because of a genuine constraint or because something is new and exciting. Most of the time, if you sit down and write out the specific technical requirements, the boring choice covers them.
The goal is not to use boring infrastructure for its own sake. The goal is to allocate your engineering attention to the things that differentiate your product. Every hour spent debugging an immature infrastructure choice is an hour not spent on the features your users care about. Boring infrastructure returns that time.