Can you really use SQLite in production?

Yes — for the right use cases. SQLite handles millions of reads per second and thousands of writes per second. If your app runs on a single server (most startups), SQLite eliminates the complexity and cost of a managed database. Rails 8 made this production-ready with Solid Queue, Solid Cache, and Solid Cable, all backed by SQLite.

When should you NOT use SQLite in production?

Don't use SQLite if: (1) You need multi-server writes (horizontal write scaling), (2) You have multiple applications writing to the same database concurrently, (3) You need to scale reads across multiple database replicas, or (4) You're running a high-traffic application with thousands of concurrent write operations per second.

How do you backup SQLite in production?

Litestream continuously replicates your SQLite database to S3 (or any S3-compatible storage like Cloudflare R2). It streams changes in real-time, so you never lose more than a few seconds of data. Recovery is a single command. It's simpler and cheaper than any managed database backup solution.

Is SQLite as fast as PostgreSQL?

For reads, SQLite is often faster because it's an embedded database — no network hop. For writes, SQLite uses a single writer lock, which is fine for most applications but becomes a bottleneck at very high write volumes (thousands of writes per second). For typical startup workloads, you won't notice a difference — and the operational simplicity is a massive win.

Blog › Lean Software

Lean Software • 4 min read • Mar 01, 2026

SQLite in Production: Why It's Ready for Your Startup in 2026

TL;DR

I run SQLite in production for justinmckelvey.com — a Rails 8 application that handles CRM, blog, booking, content engine, and email automation. No Postgres, no managed database, no monthly database bill. Just a file on disk, continuously backed up to S3 via Litestream. This is the smartest architectural decision I've made, and in 2026, it's ready for most startups. Here's why.

Why SQLite Was Considered "Not Production Ready"

For years, SQLite in production was heresy. The conventional wisdom: SQLite is for mobile apps, testing, and prototypes. Real applications use PostgreSQL or MySQL.

The concerns were legitimate:

Concurrency: SQLite uses a single writer lock — only one write at a time
Backups: You can't just pg_dump a running SQLite database
Scaling: No read replicas, no multi-server deployment
Tooling: Limited monitoring, profiling, and debugging tools compared to Postgres

These were real limitations. But the world changed.

What Changed (Rails 8 + Litestream)

Rails 8 went all-in on SQLite. The framework now ships with three SQLite-backed services that used to require Redis:

Solid Queue: Background job processing, backed by SQLite
Solid Cache: Application caching, backed by SQLite
Solid Cable: WebSocket connections, backed by SQLite

This means a Rails 8 app can run with zero external dependencies. No Redis. No Postgres. No managed services. One server, one file, one deployment.

Litestream solved backups. Litestream is a tool that continuously replicates SQLite changes to S3 (or any S3-compatible storage). It streams WAL (Write-Ahead Log) changes in real-time, giving you point-in-time recovery with seconds of data loss at most. It's simpler than any managed database backup solution I've used.

The Real-World Numbers

Here's what SQLite handles on this site:

Blog posts with rich text, categories, and full-text search
CRM with contacts, pipeline management, and tagging
Booking system with availability checking
Content engine that generates and manages social media posts
Form submissions, email templates, and interaction logging
Background jobs via Solid Queue (follow-up reminders, email sends)

Monthly database cost: $0. The SQLite file sits on a Railway persistent volume. Litestream backs it up to Cloudflare R2 (pennies/month for storage). Compare this to a managed Postgres instance: $15-50/month on Railway, Render, or Neon, and $50-200/month on AWS RDS.

When SQLite Is the Right Choice

SQLite works best when:

Single server deployment: One app, one server, one database file
Read-heavy workloads: SQLite reads are blazing fast (no network hop)
Small to medium write volume: Thousands of writes/second is fine for most apps
Simplicity matters: No database connection pools, no network configuration, no separate backup systems
Cost matters: $0/month vs $15-200/month for managed databases

For a personal business hub, a startup MVP, a content site, a booking system, or any application where one server handles all traffic — SQLite is the smart choice.

When SQLite Is NOT the Right Choice

Don't use SQLite if:

You need multiple servers writing to the same database
You have truly high write concurrency (social media scale)
You need read replicas for geographic distribution
Your application requires complex database features (JSON functions, full-text search with language stemming, etc.) — though SQLite covers most of these

The good news: by the time you outgrow SQLite, you'll have real revenue and can afford the migration. Premature infrastructure optimization is a startup killer — I've seen founders spend months setting up Kubernetes clusters for apps that serve 100 users.

How to Deploy SQLite in Production

Here's the setup I use on Railway:

Persistent volume mounted at /app/storage — this is where SQLite files live
Litestream configured to stream WAL changes to Cloudflare R2 every 10 seconds
Puma serving directly on port 3000 (no Thruster — it caused 502 errors)
RAILWAY_RUN_UID=0 environment variable for volume permissions

Total setup time: 30 minutes. Total monthly cost: $5-10 for hosting + pennies for R2 storage.

Compare this to a typical Postgres deployment: provision a managed database, configure connection pooling, set up automated backups, manage SSL certificates, monitor query performance. That's a day of DevOps work and $50+/month in ongoing costs.

The Bottom Line

SQLite in production isn't a hack. It's the right tool for the right job. If you're building a startup and your database needs are "single server, moderate traffic," SQLite with Litestream gives you everything Postgres does — at zero cost, zero maintenance, and dramatically less complexity.

Start with SQLite. Migrate to Postgres when (and if) you actually need it. That day may never come — and you'll have saved thousands of dollars and hundreds of hours of DevOps work in the meantime.

If this was useful, here are two ways I can help:

1) Get the free toolkit 2) Book a strategy call