Javlon Baxtiyorov
← Writing

Running SQLite in production stopped being a compromise

By Javlon Baxtiyorov, Senior Software Engineer · · sqlite, backend, infrastructure, architecture · 1 read

This site runs on FastAPI and a single SQLite file. In 2026 that isn't a corner I cut — it's the most defensible decision in the stack.

Running SQLite in production stopped being a compromise
Photo by Taylor Vick on Unsplash

The archive you're reading runs on one SQLite file. No managed Postgres, no connection pool, no separate database tier — just data/archive.db on the same disk as the process that reads it. For years that sentence would have read as an apology. In 2026 it reads as a decision I'd defend in any review.

What actually changed

SQLite didn't get faster because the C got cleverer. It got viable in production because the ecosystem around the file grew up:

  • WAL mode turned concurrent reads-during-writes from a footgun into the default.
  • Litestream streams the write-ahead log to object storage, so "back up the database" became a continuous, no-op concern instead of a cron job I'd forget.
  • LiteFS and libSQL put read replicas and edge-friendly copies on the table — the things you used to reach for Postgres to get.
  • Embedded replicas now serve reads in microseconds, because the data lives inside the process rather than across a socket. Cloudflare D1 pushes the same idea to the edge with single-digit-millisecond reads.

By one count, SQLite was behind 35% of new project starts in Q1 2026. That isn't nostalgia. It's people noticing the operational tax of a database tier they never needed.

The decision rule I actually use

I'm not religious about it. The rule is boring:

  • Read-heavy, single-writer, or solo-operated → SQLite, every time. The latency floor is lower and there's simply less to break at 3am.
  • Many concurrent writers, multi-region writes, true horizontal scale → Postgres, no hesitation.

The interesting news this year cut both ways. OpenAI wrote up scaling PostgreSQL to serve 800M ChatGPT users — on a single primary with around 50 read replicas. The lesson most people took was "Postgres scales further than you think." The lesson I took was the one that keeps me on SQLite: most systems are read-heavy, and a single writer goes a very long way before it's the thing that hurts.

What it costs me

Honestly: the day I need two machines writing to this database concurrently, I have a migration to do. I accepted that bill in advance because I measured how far away that day is — and for a portfolio that's almost entirely reads, it isn't on the calendar.

A database tier is infrastructure. Infrastructure you don't run is infrastructure that can't page you. That's the whole argument.

Sources: The SQLite Renaissance (DEV), Scaling PostgreSQL to 800M ChatGPT users (OpenAI), SQLite vs PostgreSQL, 2026.

← All writing Get in touch →