SQLite runs more production than the modern data stack wants you to believe

One ANALYZE command resulted in a 100x query speedup for one person. There was no need to restart the server, reconfigure the network, or receive an alert at 3am. That's the Julia Evans post about running SQLite in production that linked in my brain with a chat I had with Richard Schneeman five years ago and I couldn't shake it loose. It's one of those times where you read something, or have a conversation, and it feels like a missing half you didn't know you needed has finally slipped into place. The stack we all pretend we need Many teams opt to use managed Postgres even before experiencing load from a single user. After that, they implement a connection pooler, followed by a read replica, and then a caching layer to mask the introduced latency of the other stuff they bolted on to go fast. This represents a full stack you would normally have to create, maintain, and monitor on your own. Here's the tricky truth. The amount of work most teams have is reading-heavy. Just reading. Many readings. The numbers are almost rude As of February 2026, local SQLite p50 latency is approximately 0.01ms. Turso's Embedded Replica has a latency of about 0.02ms. When you have your Postgres database in the same region, the latency can be as low as 1 to 5ms. However, if you are using a managed Postgres like Neon, the latency might range from 3 to 10ms. For read-heavy workloads, it is 100x to 1,000x faster. Not because SQLite is magical, but because it eliminated the network. 🌐 Ben Johnson, who built Litestream and is an engineer at Fly.io, put it most starkly: "When you put your data right next to your application, you can see per-query latency drop to microseconds." Exactly. Minimizing unnecessary network calls is crucial for optimal performance. People are actually shipping this This is not a toy project. Expensify processes billions of transactions on an embedded SQLite architecture called Bedrock. They completely removed the network layer. There was no need to monitor PgBouncer. Forward Email manages millions of emails as of July 2026, using a database-per-user SQLite setup. There is one database per tenant ensuring complete isolation and avoiding any issues with noisy neighbors. PropFirm Key grew to a size where it was serving 50,000 daily visitors from one 47MB SQLite file on a single EC2 large instance. Also, in July 2026, a stress test was conducted on a Node.js social network which was running on better-sqlite3. It was able to manage 50,000 users and one million posts all stored in a single 343MB .db file. With fifty thousand users under your belt, imagine sharing a file that small with a friend via email. The catch nobody's hiding SQLite doesn't replace Postgres in all scenarios. Applications that involve frequent writing, high concurrency, and multiple writers are better off with a full database server. And that's perfectly okay. However, the exciting news is that it is closing the gap with that too. Taking SQLite, Turso's CEO Glauber Costa forked it into libsql and included native replication, embedded replicas, and vector search. The argument against replication based on the resource limitations is slowly disappearing, as the previous tradeoffs are becoming less relevant. Here's my opinion: → Operational simplicity is a feature, not a compromise. → Every layer you add is a layer you get paged for. → Most apps are read-heavy and single-node-shaped, whether we admit it or not. → "Scales to millions" is meaningless if you have thousands. The part that stings We tend to seek a sense of security in complexity. Distributed systems give an impression of importance and reliability. On the other hand, a single file seems like something you'd do back in college! 😅 However, serious is something that is functional, cost-efficient, and does not disrupt your sleep. For instance, a 47MB file that consistently serves 50,000 daily is more serious than a five-service data stack that serves a demo. I'm not suggesting you get rid of your database immediately. But try to pause and question yourself if you really need to use a heavy stack the next time. Maybe you're implementing a solution for a problem you don't have. The standard setting should be justified for how intricate it is. At present, the majority of defaults are not. So my question to you is this: If you had to choose managed Postgres or an embedded SQLite file for your next read-heavy project, it's not really about latency, is it?