Does Ruby on Rails Work With SQLite?
Ruby on Rails works excellently with SQLite and is the default database choice for new Rails projects.
Quick Facts
How Ruby on Rails Works With SQLite
SQLite is Rails' default database adapter since Rails 6.0, bundled automatically via the `sqlite3` gem. When you run `rails new myapp`, SQLite is configured out-of-the-box with zero additional setup. Rails abstracts database interactions through Active Record, so you write database-agnostic Ruby code—migrations, models, and queries work identically whether using SQLite or PostgreSQL.
The developer experience is seamless: your `config/database.yml` file already points to a local SQLite database file (typically `db/development.sqlite3`). This makes SQLite perfect for development, testing, and prototyping because there's no external database server to manage. Rails' migration system handles schema changes elegantly, and you can reset your database with `rails db:reset` in seconds.
For production, SQLite has practical limitations: it handles modest concurrent traffic but isn't ideal for high-concurrency applications or those requiring fine-grained locking. Single-writer limitations mean write-heavy workloads can bottleneck. However, for solo projects, internal tools, low-traffic web apps, or data analysis backends, SQLite in production is increasingly viable and popular.
Best Use Cases
Quick Setup
rails new myapp# Generated Gemfile includes sqlite3 automatically
# config/database.yml is pre-configured:
development:
adapter: sqlite3
database: db/development.sqlite3
pool: 5
timeout: 5000
# Create and migrate database
rails db:create
rails db:migrate
# In your Rails model (app/models/user.rb):
class User < ApplicationRecord
validates :email, presence: true, uniqueness: true
end
# Run migrations without any database server running:
class CreateUsers < ActiveRecord::Migration[7.0]
def change
create_table :users do |t|
t.string :email
t.string :password_digest
t.timestamps
end
end
endKnown Issues & Gotchas
SQLite does not support concurrent writes well; multiple processes trying to write simultaneously will experience locking delays
Fix: Use SQLite for development and testing; migrate to PostgreSQL or MySQL for production if you expect concurrent writes or scale beyond single-digit simultaneous users
SQLite's type system is dynamically flexible, potentially hiding schema errors that would fail immediately in stricter databases
Fix: Enforce column types strictly in migrations and use Rails validators; consider using a stricter database in production
Database file can become corrupted if the Rails process crashes unexpectedly during a write transaction
Fix: Regular backups, proper error handling, and using `journal_mode = WAL` in production for better crash recovery
Certain SQL features like window functions or generated columns have limited support in older SQLite versions
Fix: Ensure SQLite 3.8.0+ is installed; check SQLite documentation for feature availability
Alternatives
- •Rails + PostgreSQL: Production-grade relational database with advanced features, better concurrency
- •Rails + MySQL: Solid alternative with good performance and widespread hosting support
- •Django + SQLite: Python equivalent with similar ease-of-use for rapid prototyping
Resources
Related Compatibility Guides
Explore more compatibility guides