For most of its life, SQLite was thought of as “the little database” — great for phones and desktop apps, not something you’d run a real web backend on. That reputation is now badly out of date. SQLite at the edge has become one of the most interesting shifts in backend architecture, and it’s worth understanding why so many teams are suddenly reaching for it.
The old assumption, and why it broke
The conventional wisdom was that serious apps need a client-server database like Postgres or MySQL, with your web servers talking to it over the network. That network hop is the catch: every query pays a round-trip, and if your database lives in one region while your users are scattered across the globe, that latency adds up on every single request.
SQLite flips the model. It’s an embedded database — it runs inside your application process and reads from a local file. A query isn’t a network call; it’s a function call. There’s no connection pool, no separate server to operate, and no round-trip latency. For read-heavy workloads, that is astonishingly fast.
Why “at the edge” changes everything
Edge platforms run your code in dozens of locations close to your users. Pair that with an embedded database and something clever becomes possible: put a copy of the data in every location. Now a user in Tokyo and a user in London both hit a database that’s physically near them, reading at local-disk speed instead of crossing an ocean to a single central server.
This is exactly what projects like Turso and libSQL (a fork of SQLite built for this) enable — replicating a SQLite database to the edge and keeping the copies in sync, so reads are local and fast everywhere.
The honest trade-offs
SQLite isn’t magic, and it isn’t right for everything. The main consideration is writes. SQLite handles one writer at a time, so it shines for read-heavy applications — blogs, docs sites, dashboards, content platforms — far more than for write-heavy, high-contention systems like a busy payments ledger. The edge-replication tools soften this by routing writes to a primary and fanning reads out to replicas, but it’s the key thing to reason about before you commit.
Where it genuinely shines
If your app reads far more than it writes — and most apps do — SQLite at the edge offers a combination that’s hard to beat: near-zero read latency worldwide, dramatically simpler operations (it’s a file, not a server to babysit), and real cost savings. A surprising number of production apps that reflexively reached for Postgres would have been simpler and faster on this model.
The settings that make server-side SQLite fast
Out of the box, SQLite ships with conservative defaults tuned for embedded devices, not web servers — and most “SQLite is slow” experiences trace back to exactly this. Three pragmas transform it:
PRAGMA journal_mode = WAL; -- readers no longer block the writer
PRAGMA synchronous = NORMAL; -- sane durability/speed balance under WAL
PRAGMA busy_timeout = 5000; -- wait for locks instead of erroring instantlyWAL mode (write-ahead logging) is the important one: in the default rollback mode, a write locks out readers; under WAL, reads proceed happily while a write is in flight, which is precisely the concurrency shape a web app needs. With WAL enabled and queries hitting indexes, a single modest server serves thousands of requests per second from SQLite — the “toy database” reputation mostly comes from people benchmarking the untuned defaults.
Operational wins nobody advertises
The architecture diagram shows the latency win; day-two operations reveal quieter ones. Backups become trivial — the database is one file, and tools like Litestream continuously replicate every change to object storage (S3 and friends) for pennies, giving you point-in-time recovery with zero infrastructure. Testing gets dramatically better: your test suite runs against a real SQLite file (or :memory:) created in milliseconds per test, instead of a shared Postgres container with migration state — the same engine as production, not a mock. And N+1 queries stop mattering the way they do over a network: when a query is a function call measured in microseconds, a page that lazily runs forty small queries is still instant. Whole categories of ORM performance anxiety simply evaporate.
Knowing the ceiling before you hit it
Honest adoption means knowing what pushes you off SQLite. The single-writer design means sustained heavy write concurrency — thousands of writes per second from many sources — queues up; if your workload is genuinely write-hot, a client-server database earns its complexity. Multi-server deployments need the replication layer (Turso/libSQL, LiteFS) or a rethink, because a bare SQLite file can’t be safely shared across machines over NFS. And some Postgres luxuries — rich extensions, stored procedures, fine-grained roles — have no SQLite equivalent. The good news: the migration path is well-worn. SQLite speaks standard SQL, so an app built on it with an ORM or query builder ports to Postgres in an afternoon when (if) the ceiling arrives. Starting simple is not a trap; it’s a deferral of complexity until proven necessary.
Frequently asked questions
How big can a SQLite database get? The theoretical limit is around 281 TB; the practical answer is that multi-gigabyte SQLite databases with hundreds of millions of rows perform beautifully when indexed properly. Size is almost never the real constraint — write concurrency is.
Is SQLite reliable enough for production? It’s plausibly the most deployed and most tested piece of database software on Earth — it runs in every phone, browser, and operating system, and its test suite is legendarily thorough. Reliability is the last reason to avoid it.
Should I use SQLite or Postgres for my next project? Ask one question: will multiple servers need to write to the same data simultaneously? If no — a typical single-region app, a content site, an internal tool — SQLite’s simplicity is a gift. If yes, or if you need Postgres-specific features, start with Postgres. Both are excellent; the mistake is defaulting to the heavier one out of habit.
The takeaway
The rise of SQLite at the edge is a reminder that the “obvious” architecture isn’t always the right one. An embedded database replicated close to your users turns database latency from a constant tax into a non-issue for reads. It won’t replace Postgres for every workload, but for the read-heavy majority, it’s a genuinely compelling default worth evaluating on your next project.
