Why SQLite Is Enough for Most SaaS Apps

Every new SaaS project seems to start with the same stack: a managed PostgreSQL instance, connection pooling, migration tooling, and a monthly bill before a single user signs up. But what if that complexity is solving a problem you don't actually have?

SQLite ships with every major programming language runtime, stores your entire database in a single file, and handles far more traffic than most developers assume. For the majority of SaaS applications, it is not just adequate — it is the better choice.

The traffic reality check

Most SaaS products never reach the scale where SQLite becomes a bottleneck. A single SQLite database in WAL (Write-Ahead Logging) mode comfortably handles tens of thousands of requests per day on modest hardware. That covers the vast majority of B2B tools, internal dashboards, niche marketplaces, and developer utilities.

The chart below compares how well each database fits different traffic levels, from a small side project to a high-traffic consumer app.

SQLite vs PostgreSQL suitability by traffic scale

Below roughly 100K monthly requests, SQLite scores higher on overall suitability when you factor in operational simplicity, cost, and performance. PostgreSQL pulls ahead only at scale levels most SaaS apps never reach.

Where SQLite wins

Zero operational overhead

There is no database server to provision, monitor, patch, or restart. No connection pool to tune. No credentials to rotate. Your database is a file on disk. Backups are a file copy — or a single sqlite3 .backup command.

For a solo founder or a small team, this is not a minor convenience. It is hundreds of hours saved over the life of a product.

Reads are extremely fast

SQLite runs in the same process as your application. There is no network round-trip, no serialization overhead, no TCP handshake. A typical read query on SQLite completes in microseconds, not milliseconds. For read-heavy SaaS workloads — dashboards, content platforms, analytics views — this latency advantage is significant.

Deployment is trivial

Your database travels with your application. A single binary or container image contains everything. No Terraform modules for RDS. No database migration CI step that talks to a remote host. No staging environment with a separate database that drifts out of sync.

Cost is zero

SQLite is public domain software. There are no per-connection fees, no managed database bills, no surprise charges for IOPS. The money you save on infrastructure in year one can fund actual product development.

The write bottleneck — and why it rarely matters

SQLite uses a single-writer model. Only one write transaction can proceed at a time. This is the constraint that sends people running to PostgreSQL.

But consider the actual write patterns of a typical SaaS app:

  • A user updates their profile: a few writes per session
  • A team creates a project: one write
  • A webhook logs an event: one write per event

Even at 50 write transactions per second, SQLite keeps up without breaking a sweat. You would need sustained, concurrent, heavy write loads — think thousands of simultaneous writers — before this becomes a real problem.

WAL mode is the key enabler here. It allows readers to proceed without blocking on writes, and writes to proceed without blocking readers. Enable it with a single pragma:

PRAGMA journal_mode=WAL;

When to actually move to PostgreSQL

There are legitimate reasons to use a client-server database. Be honest about whether they apply to you today, not in some hypothetical future:

  • You need multiple application servers writing to the same database simultaneously
  • You rely on PostgreSQL-specific features like LISTEN/NOTIFY, full-text search with custom dictionaries, or advanced JSON operators
  • Your write throughput genuinely exceeds what a single writer can handle (measure it, don't guess)
  • You need row-level security or complex role-based access at the database layer

If none of these apply, PostgreSQL is not giving you anything that justifies the operational cost.

Real-world examples

Pieter Levels runs multiple profitable SaaS products on SQLite. Expensify used SQLite in production for years. The SQLite website itself runs on SQLite and serves millions of requests. Tailscale uses SQLite for their coordination server.

These are not toy projects. They are real products with real users and real revenue.

A practical setup for production SaaS

If you decide to use SQLite for your SaaS app, these pragmas will get you production-ready behavior:

PRAGMA journal_mode=WAL;
PRAGMA busy_timeout=5000;
PRAGMA synchronous=NORMAL;
PRAGMA cache_size=-64000;
PRAGMA foreign_keys=ON;

Pair this with a daily backup script — copy the database file to a second disk or cloud storage — and you have a setup that will serve you well from zero users to a meaningful business.

Stop over-engineering your database layer

The best infrastructure decision is the one that lets you ship faster and worry less. For most SaaS applications, SQLite is that decision. It is fast, reliable, free, and simple. You can always migrate later if you genuinely outgrow it — but the odds are, you never will.

Start with SQLite. Build your product. Solve real problems instead of imaginary scaling ones.