Rails 8 + SQLite — Why It Works in Production
The era of no PostgreSQL has arrived — SQLite in production proven by 37signals
Starting with Rails 8, SQLite is officially recommended as a production database. The perception that "SQLite is for development only" is now outdated.
Why SQLite Now?
The Solid series introduced in Rails 8 (Solid Queue, Solid Cache, Solid Cable) is the game changer. Previously you needed Redis (cache, job queue) and PostgreSQL (DB) separately, but now one SQLite handles DB + cache + job queue + WebSocket entirely.
37signals (makers of Basecamp, HEY) uses this setup in actual production. DHH (Rails creator) himself said "PostgreSQL is overkill for most web apps."
Why SQLite Works in Production
- Serverless — runs as a single file with no separate process/port. No DB server management
- WAL mode — Write-Ahead Logging dramatically improves read/write concurrency
- Solid series — cache, jobs, cable all handled by SQLite without Redis/Memcached
- Simplified deployment — no DB server config, connection pool management, or migration ordering worries
- Cost reduction — zero managed DB costs (RDS/CloudSQL)
- Easy backup — one file copy = complete backup
When PostgreSQL Is Still Needed
Very high concurrent writes (thousands of INSERTs per second)
Multiple servers accessing the same DB (SQLite is single-server)
PostgreSQL-specific features needed (jsonb, Full Text Search, PostGIS)
Large teams with existing PostgreSQL infrastructure
For most small-to-medium apps, solo/small team projects, SaaS MVPs, and side projects, SQLite is sufficient.
Rails 8 Solid Series — All SQLite, No Redis/PostgreSQL
| Feature | Before (Rails 7) | Now (Rails 8) |
|---|---|---|
| Database | PostgreSQL / MySQL | SQLite (WAL mode) |
| Background Jobs | Sidekiq + Redis | Solid Queue (SQLite) |
| Cache | Redis / Memcached | Solid Cache (SQLite) |
| WebSocket | Action Cable + Redis | Solid Cable (SQLite) |
| External Services | PostgreSQL + Redis (min 2) | None (files only) |
Choose SQLite
- ✓ Solo or small team
- ✓ SaaS MVP, side projects
- ✓ Minimize infrastructure costs
- ✓ Read-heavy apps
- ✓ Single server sufficient
Choose PostgreSQL
- ✓ Thousands of concurrent writes/sec
- ✓ Multi-server setup needed
- ✓ jsonb, PostGIS, FTS needed
- ✓ Existing PostgreSQL infrastructure
- ✓ Horizontal scaling plans
Key Points
Rails 8 projects use SQLite by default (no extra setup needed)
Verify WAL mode enabled in config/database.yml (Rails 8 default)
Enable Solid Queue (jobs), Solid Cache (cache), Solid Cable (WebSocket)
Deploy with Kamal or Fly.io — no DB server setup at all
Use json type instead of jsonb (SQLite doesn't support jsonb)
Pros
- ✓ Zero infrastructure — no DB server, Redis, or Memcached needed
- ✓ Simplified deployment — DB migration by simple file copy
- ✓ Zero RDS/CloudSQL costs — saves tens of dollars monthly
- ✓ Minimal latency — direct disk access with no network hop
- ✓ Production-proven by 37signals
Cons
- ✗ Single server only — no multi-server concurrent access
- ✗ Write contention — performance may degrade with heavy INSERTs
- ✗ No PostgreSQL-specific features (jsonb, PostGIS, Full Text Search)
- ✗ No horizontal scaling — only vertical scaling for traffic spikes