How (and why) to run SQLite in production
summary
Argues that SQLite can run production Rails apps if four concrete fixes are applied and automated: set default transaction mode to immediate transactions to avoid sqlite3 busy errors; replace the C busy handler with a Ruby busy handler that uses sleep to release the GVL and a non-blocking fair busy handler (1ms retries) to flatten P95/P99 latency; run SQLite in WAL mode; use separate reader/writer connection pools plus point‑in‑time backups via lightstream backups. An enhanced_adapter gem implements these changes and load tests show large latency gains.
AI-written summary · about
chapters (9)
- 0:00Introduction and speaker background
- 2:54Why SQLite in production?
- 7:38Cost and performance advantages
- 13:21Making SQLite production-ready
- 15:50Deep dive into performance optimizations
- 36:45Key performance techniques
- 48:11Enhanced adapter gem overview
- 52:27Resilience and future of Rails
- 59:57Q&A session
related talks
45mSQLite on Rails: Everything you need to know
30mUse SQLite in production
01h 56mSQLite on Rails: From rails new to 50k concurrent users and everything in between
01h 56mSQLite on Rails: From rails new to 50k concurrent...
01h 56mSQLite on Rails: From rails new to 50k concurrent users and everything in between
31mSQLite, the World's Most Ubiquitous Yet Little-Known Database
39mBuilding Production Applications Using Go
19mSQLite - The most overlooked database