Testing: in-memory database
This course asks whether a Rails test suite should run against an in-memory SQLite database, and answers by measuring. It profiles a 1,206-example RSpec suite and compares database round trips with boot time and slow sandbox examples. It explains how SQLite's :memory: mode and shared cache work. It then weighs PostgreSQL features such as jsonb, pg_trgm and ILIKE against the risk of silent divergence. It also covers transactional tests, other ways to speed up the suite, and the projects where an in-memory database fits.
What you'll learn
- ✓Profiling an RSpec suite with --profile before optimizing
- ✓How SQLite :memory: databases, shared cache URIs and connection pools interact
- ✓Why jsonb, pg_trgm, ILIKE and window functions make SQLite tests diverge from production
- ✓How transactional fixtures and savepoints isolate each example
- ✓Practical speedups: one file per run, --only-failures, random order, build over create, parallel_tests
- ✓When an in-memory database or in-memory test double is the right choice
Where the time actually goes
This course is about a well-known trick: run the test suite against an in-memory SQLite database instead of a real one, and watch it get faster. The trick is real. Whether it helps you is a question with a measurable answer, and measuring first is the entire discipline.
Read the full lesson free →Curriculum
7 lessonsWhere the time actually goes
Profiles a 1,206-example suite with rspec --profile and shows database transport is about 3 of 70 seconds.
What an in-memory database actually is
Explains SQLite's :memory: mode, why connection pools need the shared cache URI, and loading the schema on boot.
What it would cost here
Shows how jsonb columns, pg_trgm, ILIKE and window functions would make SQLite tests diverge silently from production.
Transactional tests: the real mechanism
Explains how transactional fixtures roll back each example, how savepoints work, and where separate connections break them.
The levers that actually work
Ranks the options that help here: one file per run, --only-failures, random order, build over create and parallel_tests.
When in-memory is the right answer
Describes where in-memory fits: gems, engines, plain-schema apps with real-database CI, and cache, queue or mail doubles.
Putting it together: a decision, measured
Reviews the measured decision step by step and the general rule of profiling before choosing any optimization.