Rails on SQLite: new ways to cause outages
10 hours ago
- #Deployment
- #Rails
- #SQLite
- SQLite simplifies Rails app deployment by eliminating the need for separate database, Redis, and file storage services.
- SQLite's in-process nature means no database connection errors but requires persistent storage to prevent data loss in containerized environments.
- Running background jobs in threads within the same process can reduce RAM usage and simplify deployment for small applications.
- Vertical scaling is necessary with SQLite, as horizontal scaling is limited by the single-file database constraint.
- SQLite's Write-Ahead Log (WAL) allows concurrent reads but introduces complexity in backup and recovery strategies.
- Using multiple SQLite files for different purposes (e.g., ActiveRecord, Rails cache, background jobs) can reduce contention and improve performance.
- Deploying SQLite-based apps can result in downtime due to the single-server limitation, but troubleshooting is simplified.
- Litestream provides backup and replication for SQLite by streaming WAL entries to S3-compatible storage.
- LiteFS offers distributed replication for SQLite but comes with trade-offs like stale reads and potential data loss during failures.