The numbers are in, and they’re embarrassing. On Wednesday, a blog post titled “SQLite Is All You Need for Durable Workflows” surged to the top of Hacker News, racking up 649 points and hundreds of comments before the workday ended. The post — which argues that a single embedded database file handles workflow state more cleanly than the distributed message-broker circus most teams reach for — didn’t go viral because it was novel. It went viral because it landed as a confession. The developers reading it had all, at some point, built a Kafka pipeline for something that would have run fine on a laptop.

The SQLite revival, with its ecosystem of Turso, Cloudflare D1, and LiteFS, has been building for two years. But the workflow argument hits a different nerve. Durable execution — the orchestration of multi-step processes across failures, retries, and state transitions — was supposed to be the final boss of complexity. The thing that justified your Kubernetes cluster. Instead, we’re learning it fits in a file.

The Embarrassment of Enough

Turso raised $30 million in 2024. Cloudflare’s D1 reached general availability the same year. These aren’t scrappy experiments — they’re funded, marketed products with pricing tiers and SLA pages. And the pitch is, essentially: you didn’t actually need what you’ve been paying for.

This isn’t a technology story. It’s a procurement story. For fifteen years, the stack defaulted toward maximum blast radius: microservices for every function, message queues between every microservice, orchestrators to manage the message queues, monitoring tools to watch the orchestrators. The enterprise assumption was that any software that succeeded would eventually need all of it, so you might as well start there. What the SQLite durable-workflows argument exposes is that the assumption was wrong.

The viral post doesn’t prove SQLite is special. It proves that the complexity ceiling for most production workloads — even durable ones — was never as high as the ecosystem needed you to believe.

What the Architecture Astronauts Missed

Here’s the specific thing the conventional architecture advice of the late 2010s overlooked: most workflows don’t need to run on dozens of nodes. A durable workflow, in practice, is often a state machine tracking a dozen steps — a loan approval, a customer onboarding flow, a payment retry loop. The failure tolerance comes from write-ahead logging, not from horizontal scaling. SQLite has had that since 2010.

As one engineer on a trading desk put it to me during the afternoon lull between market close and reconciliation: “We ran the numbers on our workflow engine — the throughput vs. the cost of running Temporal. The throughput was five requests per second. Five. We were running fleet infrastructure for less traffic than a moderately popular blog.”

The architecture astronauts — the ones who diagrammed systems in terms of thousand-node clusters and eventual consistency tradeoffs — designed for the top 1% of scale and convinced the other 99% to follow them. That’s the real contrition behind this week’s viral post: not “SQLite is better than Kafka” but “I built a solving-machine for problems I categorically did not have.”

What Gets Built When Nobody’s Watching

This is where the contrarian overshoot-careens into something genuinely interesting. If a generation of infrastructure was designed for the top of the scale curve, what was not built because that infrastructure existed? The cost isn’t just the enterprise bills for unnecessary Kafka clusters. It’s the database abstraction libraries that didn’t get written because Postgres was assumed. It’s the workflow patterns that never shipped because every engineer believed durable execution required a server farm.

SQLite-based workflows aren’t a technological breakthrough. They’re a retrospective — a reminder that a lot of the hard problems in computing were solved decades ago, and the past decade layered complexity on top of that not because it was needed, but because it was available and fundable. The durable-workflow post went viral because it gave people permission to stop pretending their five-requests-per-second pipeline was a worldwide distributed system.

The broader lesson is uncomfortable for the industry: the tooling we built for hyperscale companies turns out to have been mostly for the hyperscale companies. The rest of us were running on the same complexity treadmill because the advice, the blog posts, and the conference talks all assumed we’d need it someday. Most of us won’t. A SQLite file and a single server would have been fine.

Sources