SQLite vs PostgreSQL for Side Projects in 2026: When to Use Which

You’re starting a side project — a SaaS tool, a personal app, a weekend experiment that might turn into something real. The first architectural decision you hit is the database. Your instinct says PostgreSQL because that’s what “real” apps use. But then you see that every new Rails, Django, and Go framework defaults to SQLite, and tools like Litestream and LiteFS have made SQLite replication production-viable. In 2026, the question isn’t “is SQLite good enough?” — it’s “at what point does PostgreSQL become necessary?”

TL;DR

SQLite is the right default for side projects, single-server apps, and anything under ~100 concurrent write-heavy users. Zero ops, zero cost, sub-millisecond reads, single-file deployment.
PostgreSQL becomes necessary when you need concurrent writes from multiple servers, advanced query features (full-text search, JSONB indexing, CTEs with writeable side effects), or managed replication.
The crossover point for most apps is around 100–500 concurrent users with write-heavy workloads, or the moment you need a second application server connecting to the same database.
In 2026, SQLite with WAL mode handles far more than most developers expect. Don’t switch to Postgres out of habit — switch when you hit a specific limitation.

How They Actually Differ

Architecture in One Sentence Each

SQLite is an embedded database — a single file on disk, accessed via a C library linked directly into your application process. There is no server, no daemon, no network protocol. Your app reads and writes the file directly.

PostgreSQL is a client-server database — a separate process (or cluster of processes) that your application connects to over TCP or Unix sockets. It manages its own memory, storage, connections, and query planning independently.

This architectural difference drives every practical trade-off.

Performance: It’s Not What You Think

For read-heavy workloads, SQLite is often faster than PostgreSQL. There’s no network round-trip, no connection overhead, no query plan caching across connections. A typical SQLite SELECT on an indexed column completes in 0.01–0.05ms. The same query on a local PostgreSQL instance takes 0.5–2ms due to protocol overhead.

For write-heavy workloads, PostgreSQL pulls ahead. SQLite uses a single writer lock — only one transaction can write at a time (even in WAL mode, which allows concurrent reads during writes). PostgreSQL supports true multi-writer concurrency with row-level locking. If your app does 50+ writes per second from multiple threads, SQLite’s write throughput becomes a bottleneck.

The Concurrency Reality

In WAL (Write-Ahead Logging) mode, SQLite handles:

Unlimited concurrent readers — no blocking
One writer at a time — other writers queue and retry
Practical write throughput: ~1,000–5,000 transactions/second on SSD (depending on transaction size)

For a side project with 10–100 active users, this is more than enough. A typical web request does 1–3 writes. At 100 concurrent users with 1 request/second each, you need ~100–300 writes/second — well within SQLite’s capacity.

PostgreSQL handles all of this plus multi-server writes, but you’re paying for operational complexity you don’t yet need.

The Real Comparison

Factor	SQLite	PostgreSQL
Setup time	0 — it’s a file	5–30 min (local) or managed service
Monthly cost	$0	$0 (local) or $5–$50 (managed)
Deployment	Copy one file	Provision and maintain a server
Backups	`cp database.db backup.db`	pg_dump, WAL archiving, or managed snapshots
Concurrent readers	Unlimited	Unlimited (with connection pooling)
Concurrent writers	1 (queue others)	Many (row-level locking)
Full-text search	FTS5 (basic but functional)	Excellent (tsvector, GIN indexes)
JSON support	json_extract, basic	JSONB with indexing, operators
Replication	Litestream, LiteFS (append-only)	Streaming replication, logical replication
Extensions	Limited (loadable extensions)	Rich ecosystem (PostGIS, pgvector, pg_cron)
Multi-server access	No (single process)	Yes (client-server)

The Deployment Advantage Nobody Talks About

The single most underrated SQLite benefit is deployment simplicity. Your entire database is one file. Deploy your app to a VPS, a Docker container, or a $5 Fly.io machine — the database travels with it. No connection strings, no managed database service, no VPC peering, no connection pooling.

For side projects, this means:

Total hosting cost: $5–$10/month (one small VPS or Fly.io machine)
Backup strategy: Litestream streams WAL changes to S3 for ~$0.01/month
Zero database ops: No vacuuming, no connection pool tuning, no PgBouncer

Compare to PostgreSQL on a managed service:

Neon free tier: Generous but with cold-start latency
Supabase free tier: Good but shared resources
AWS RDS: Starting at ~$15/month for the smallest instance
Self-hosted: You’re now a DBA

When to Start with SQLite

Solo developer or tiny team building a web app with a single server
Read-heavy apps: blogs, dashboards, internal tools, content sites
Prototyping: You can always migrate to Postgres later; starting with SQLite lets you ship faster
Edge/embedded deployment: Each user or tenant gets their own SQLite database (per-tenant isolation)
Apps where data locality matters: SQLite on the same machine as the app eliminates network latency entirely

The SQLite 2026 Stack

The modern SQLite deployment stack that makes this production-viable:

App Server (Node.js/Go/Python)
  └── SQLite (WAL mode, PRAGMA journal_mode=WAL)
        └── Litestream → S3 (continuous backup)

Critical PRAGMAs for production:

PRAGMA journal_mode = WAL;
PRAGMA busy_timeout = 5000;
PRAGMA synchronous = NORMAL;
PRAGMA foreign_keys = ON;
PRAGMA cache_size = -20000;  -- 20MB cache

When to Switch to PostgreSQL

Switch when you hit one of these concrete walls — not before:

Multiple application servers need to write to the same database. SQLite can’t do this. The moment you scale horizontally, you need a database server.
Write contention is causing SQLITE_BUSY errors under load that busy_timeout can’t handle. This typically happens above 500+ writes/second.
You need advanced query features: writeable CTEs, LISTEN/NOTIFY, row-level security, advanced JSONB querying with GIN indexes, or PostGIS for geospatial data.
You need pgvector for AI/embedding workloads — see our pgvector vs Pinecone comparison.
Your dataset exceeds available RAM and you need PostgreSQL’s more sophisticated query planner and parallel query execution.

Migration Is Not That Hard

SQLite to PostgreSQL migration for a typical web app takes a weekend:

Export schema: sqlite3 db.sqlite .schema > schema.sql
Adjust SQL syntax (SQLite-isms → Postgres-isms: AUTOINCREMENT → SERIAL, datetime('now') → NOW(), etc.)
Export data as INSERT statements or CSV
Import to Postgres
Update your ORM connection string

Most ORMs (Prisma, Drizzle, SQLAlchemy, Django ORM) abstract the database layer enough that your application code barely changes. The migration isn’t zero-effort, but it’s a one-time cost measured in hours, not weeks.

Common Mistakes

Starting with Postgres “because we might scale.” You’re paying the operational cost of a database server from day one for a scaling event that may never happen. Start simple.
Using SQLite without WAL mode. Default journal mode uses exclusive locks for both reads and writes. WAL mode is strictly better for web apps — always enable it.
Ignoring busy_timeout. Without it, concurrent writes return SQLITE_BUSY immediately instead of waiting. Set it to at least 5000ms.
Putting SQLite on a network filesystem (NFS, EFS). SQLite requires POSIX file locking, which network filesystems handle poorly or not at all. The database must be on local disk.
Over-indexing early. Both databases perform well with proper indexes, but SQLite’s query planner is simpler. Use EXPLAIN QUERY PLAN liberally.

For more on database architecture decisions, see our database design patterns guide and Redis caching strategies.

FAQ

Can SQLite handle a SaaS with paying customers?

Yes — many production SaaS apps run on SQLite. Pieter Levels (Nomad List, Remote OK) runs multi-million-dollar businesses on SQLite. The constraint is architectural (single server), not reliability.

What about Turso / libSQL — is that a third option?

Turso is a hosted, distributed SQLite-compatible database built on libSQL. It gives you SQLite’s simplicity with edge replication and multi-tenant support. It’s a compelling middle ground if you want SQLite semantics with horizontal read scaling. Worth evaluating for edge-heavy apps.

Should I use an ORM or raw SQL with SQLite?

For side projects, an ORM (Drizzle, Prisma, SQLAlchemy) saves time and makes future migration to Postgres trivial. For performance-critical paths, drop to raw SQL. The beauty of SQLite is that raw SQL is fast enough that you rarely need to optimize.

Is SQLite safe for concurrent web requests?

Yes, in WAL mode with busy_timeout set. Concurrent reads are unlimited. Concurrent writes are serialized but typically complete in under 1ms each, so queuing is invisible to users at moderate scale.

How do I back up SQLite safely?

Never copy the database file while the app is running — you’ll get a corrupted copy. Use Litestream for continuous streaming backups to S3, or use SQLite’s .backup command which handles locking correctly.

Bottom Line

In 2026, SQLite is the right default for side projects and single-server apps. It’s faster for reads, simpler to deploy, costs nothing to run, and handles more concurrent users than most developers realize. Switch to PostgreSQL when — and only when — you need multi-server writes, advanced query features, or the PostgreSQL extension ecosystem. The migration path is well-worn and takes hours, not weeks. Don’t pay the complexity tax of a database server until the simplicity of a database file stops being enough.

Product recommendations are based on independent research and testing. We may earn a commission through affiliate links at no extra cost to you.