Why SQLite Is the Right Database for Your First SaaS

Every time someone ships a side project, the same debate erupts: "Why didn't you use PostgreSQL?" As if choosing SQLite for a product with zero users is some kind of engineering malpractice.

Here's the thing: we run four production SaaS products on SQLite. They handle signups, API key management, usage tracking, webhook capture, and Stripe checkout flows. They work fine.

The Case for SQLite

Zero operational overhead. No database server to configure, monitor, backup, or restart. No connection pooling. No password management. No "the database is down" pages. Your data lives in a single file alongside your application.

Deployment simplicity. One Docker container. Not two. Not three with a connection pooler. One. Your docker-compose.yml stays readable. Your CI/CD pipeline stays simple. Your bill stays small.

Performance that doesn't matter yet. SQLite handles thousands of reads per second and hundreds of writes per second on modest hardware. If your SaaS has fewer than 10,000 users — and it does, because you just launched — SQLite is not your bottleneck. Your marketing is.

Backup is cp. Want a backup? Copy the file. Want to inspect production data locally? Copy the file. Want to test a migration? Copy the file. No pg_dump, no credentials, no connection strings.

The Common Objections

"SQLite doesn't handle concurrent writes"

WAL mode (Write-Ahead Logging) handles concurrent reads and serialized writes. For an API that processes a few hundred requests per minute, this is a non-issue. If you're worried about write contention, you're optimizing for a problem you don't have.

"You can't scale horizontally"

Correct. You also can't scale horizontally with a single PostgreSQL instance. Horizontal scaling is a problem for products with product-market fit, paying customers, and growth. Not for products with a landing page and a hope.

"What about migrations?"

SQLite supports ALTER TABLE for adding columns and indexes. For anything more complex, you write a migration script that creates a new table, copies data, and swaps. This is the same thing ORMs do behind the scenes — you're just doing it explicitly.

When to Actually Switch

Move to PostgreSQL when:

• Write volume exceeds what WAL mode can handle (~500 writes/sec sustained)
• You need full-text search beyond SQLite's FTS5
• You're running multiple application instances that need shared state
• Your data model needs features SQLite lacks (JSONB operations, array types, CTEs with write operations)

Notice what's not on this list: "because PostgreSQL is more professional." Technology choices aren't résumé items. They're trade-offs.

Our Setup

Each of our four products — DocuMint, CronPing, FlagBit, and WebhookVault — runs FastAPI with SQLite. The database file lives in a Docker volume. Backups happen by copying the volume. Migrations run on container startup.

Total database infrastructure cost: $0. Total database-related incidents: 0. Total time spent configuring database servers: 0.

Ship the thing. Use SQLite. Upgrade when the data tells you to.