Rails 8 solo developers bet on SQLite for production, ditching Postgres complexity
Rails 8 ships with a controversial default: SQLite for everything. Not just data storage, but background jobs (Solid Queue), caching (Solid Cache), and WebSocket pub/sub (Solid Cable). The Rails core team is making a bet that solo developers waste more time managing infrastructure than they gain from Day One Postgres.
The trade-off is real. SQLite's single-writer architecture means one concurrent write at a time, even with WAL mode enabled. Postgres handles thousands of simultaneous connections via MVCC. For a team building a high-traffic API or multi-tenant SaaS, that's a non-starter.
But for the solo developer shipping an MVP? The calculus has changed.
What NVMe actually solved
The migration from SQLite to Postgres in the 2000s made sense when storage meant spinning disks. Random I/O was slow. Concurrent writes locked entire tables.
Modern NVMe SSDs hit 3GB/s reads and hundreds of thousands of IOPS. At that speed, network latency to a separate Postgres process becomes the bottleneck. SQLite runs in-process, no TCP round trips. Function calls instead of network packets.
Benchmarks show SQLite faster than Postgres on simple reads and small queries when both are on the same machine. Complex joins or heavy write workloads still favor Postgres, but the gap narrows when you remove the network tax.
The backup problem isn't solved, just shifted
The article recommends Litestream for streaming WAL updates to S3. That works, until you need point-in-time recovery across multiple databases or want to restore a specific table without pulling the entire file. Postgres tooling for selective restores is more mature.
GitHub Actions workflows for SQLite backups typically tar the database file and push to S3 on cron. Simple, but no continuous replication. Turso offers managed SQLite with built-in replication, though that reintroduces vendor lock-in the single-file approach was meant to avoid.
What this means in practice
Rails 8's Solid suite collapses three services (app server, Redis, Postgres) into one. For solo developers, that's less to monitor, fewer connection pool errors, faster iteration.
The real question: when do you migrate? At 100 concurrent users? When writes start queuing? When you hire your first backend engineer?
History suggests the answer is "later than you think." SQLite can handle moderate traffic (thousands of transactions per second) with proper tuning. Most startups fail before hitting those limits.
Worth noting: if you do outgrow SQLite, you have revenue to fund the migration. That's a better problem than over-architecting for scale you never reach.
What to watch
Rails 8 adoption among solo developers will test whether the simplicity trade-off is worth the concurrency ceiling. Early production deployments should surface the real-world write bottlenecks that benchmarks miss.
The pattern matters beyond Rails. Django and Flask developers are asking the same questions about SQLite in production. If the one-person stack works, expect other frameworks to follow.