Postgres or SQLite for a Small App, and When It Actually Matters

Five years ago, "Postgres or SQLite for a small app" wasn't much of a question. SQLite was for embedded use and test suites. Postgres was for anything real. That answer has quietly changed. SQLite is now a legitimate production database for a large class of small-to-medium apps, and the reasons matter.

This post is a working take on the current version of the trade-off. Not ideological. Practical. When SQLite fits, when Postgres still wins, and how to decide without hedging.

What changed about SQLite

Two things. First, hosted SQLite services — Turso, LiteFS, Cloudflare D1 — solved the historic downsides. You can now run SQLite in production with replication across regions, backups, and edge distribution. It's not a local file anymore.

Second, the app-runtime story caught up. Deploying an app that talks to a local SQLite file is now standard with modern platforms — Fly, Railway, Cloudflare. You don't need to run a separate database server for many small apps.

The result is a real choice where there used to be one obvious answer.

When SQLite fits

SQLite works well for a specific shape of application. The shape shows up more often than founders expect.

Read-heavy apps

SQLite is very fast at reads. If your app is mostly reads with occasional writes, SQLite outperforms Postgres in latency because there's no network hop to the database — it lives inside your app process or on the same disk.

Small-to-medium data sizes

SQLite handles gigabytes of data comfortably. Not petabytes, but comfortably enough for most SaaS at pre-Series-A stages. A database under 100GB is well within SQLite's range.

Simple concurrency

SQLite has a single-writer model — one write at a time, though modern WAL mode makes this less painful than it used to be. If your app has many concurrent readers and moderate writers, this works fine. If your app has thousands of concurrent writes per second, it doesn't.

Small teams

SQLite is one file, or with a hosted service, one managed service. No separate database to provision, patch, or monitor. For a team without a DevOps person, this simplicity is worth a lot.

When Postgres still wins

Postgres remains the right default in most cases. Here's when it clearly is.

Write-heavy or multi-writer workloads

If multiple app instances write frequently to the same data, Postgres handles the concurrency more gracefully. SQLite's single-writer model becomes a bottleneck at scale.

Complex data needs

JSON with rich indexing, geo queries with PostGIS, full-text search with tsvector, custom types. Postgres has all of these built in. SQLite has partial support for some, none for others.

Multi-region write access

Turso and LiteFS handle multi-region reads well but write coordination is trickier than in a managed Postgres. If your app has global users all writing to the same data, Postgres with a managed regional replica setup is more predictable.

Anything an ORM makes assumptions about

Most ORMs support SQLite officially, but the ecosystem's tooling — migrations, admin panels, third-party libraries — usually assumes Postgres. You'll hit small friction on the SQLite path that doesn't exist on the Postgres one.

What the hosted SQLite services offer

Not all "SQLite in production" is the same.

Turso and libSQL

SQLite with a distributed layer on top. Reads are fast because replicas live near the app. Writes go to a primary and replicate out. Good for read-heavy workloads with global users.

Fly LiteFS

A filesystem that replicates SQLite files across regions on Fly. Simpler mental model — it really is just SQLite — but tied to the Fly platform.

Cloudflare D1

Cloudflare's managed SQLite. Runs on Workers. Good for edge-first apps but has some restrictions on transaction handling and query complexity that catch teams off guard.

Local file with backups

The simplest version. Run SQLite as a file on your app's disk, back it up on a schedule with Litestream or a similar tool. Zero external service, minimum operational surface. Best for very small apps that don't need horizontal scale.

The migration question

"Can I start on SQLite and move to Postgres later?" is asked in almost every scoping call now.

Technically yes. The SQL dialects are similar enough that most schemas port with minimal changes. The migration tools — pgloader, or dumping and reloading — handle typical schemas.

Practically: it's a project. Any nontrivial app has SQLite-specific queries, indexing decisions, or transaction patterns that need adjustment. Budget a couple of engineering weeks, not a couple of hours.

The safer path is to pick the right database for the medium term. If you're pretty sure you'll be on Postgres in a year, start there. If you're pretty sure SQLite will still fit, start there. Don't pick SQLite as a "temporary" choice you plan to migrate — you'll ship the migration on a bad week.

What we usually recommend

For a new SaaS with a team of one to three, Postgres is still our default recommendation. The ecosystem, the tooling, the ORM support, and the hosted options — Neon, Supabase, RDS — are all mature. The operational cost is minimal on modern platforms.

For a read-heavy content-style app with global users, or a very small utility app, SQLite via Turso or LiteFS is legitimate. Faster reads, simpler operations, and the modern hosted services close the historic gaps.

For anything with complex data needs — geo, full-text search, ML embeddings, rich JSON — Postgres. Especially since it has vector search now with pgvector, which matters for AI-heavy products.

Our Postgres vs MongoDB post covers a different corner of the database question.

Mistakes we see

Picking SQLite because it feels faster in benchmarks. Local reads are faster because there's no network. That advantage evaporates once you distribute across regions. Pick the database for your actual workload, not a laptop benchmark.

Picking Postgres because "everyone uses it" and then never using its features. If you're storing JSON blobs and querying by ID, most of Postgres's value goes unused. Fine choice, but don't let complexity intimidate you into never simplifying.

Ignoring backup and restore. Both databases can be backed up. Both need it. SQLite backups via Litestream are actually simpler than many Postgres backup setups. Test the restore.

Assuming SQLite doesn't scale. Fly, Turso, and others run large real workloads on SQLite. The old rule "SQLite for prototypes, Postgres for real" is outdated. Test with real data before assuming.

Common misconceptions

"SQLite isn't for production." It runs in every browser, every phone, and many production apps of substantial scale. It's not a toy.

"Postgres is always more powerful." More features, yes. More power for your specific workload, only if you use those features. A simpler tool that fits is often better than a more capable one that doesn't.

"Serverless can't use SQLite." Turso, D1, and libSQL run natively on serverless platforms. The mental model is different, but the fit is real.

Frequently asked questions

Final take

The database choice used to be automatic. It isn't anymore. For a specific class of small apps, SQLite with a modern hosted layer is a legitimate production choice. For most everything else, Postgres remains the right default. Neither is wrong; both are right for different shapes.

If you're picking a database for a new project and want a second opinion on the fit, book a call. We'll walk through the workload and tell you what we'd pick.