Solid Queue: database-backed
This course looks at how Solid Queue, Solid Cache and Solid Cable connect to the database in a Rails app. Each one declares its own connects_to, so every process holds four connection pools: primary, queue, cache and cable. Development and test point those pools at four separate Postgres databases. Production puts primary, queue and cable in one database and gives the cache its own. The lessons also cover the connection cost of that shape, how db:prepare finds each schema file, and why each environment differs.
What you'll learn
- ✓How connects_to gives each Solid gem its own connection pool
- ✓Why development and test use four separate Postgres databases
- ✓Why production shares one database for primary, queue and cable but splits out the cache
- ✓What extra pools against one Postgres server cost in connections
- ✓How db:prepare loads each role's schema file and what migrations_paths is for
- ✓Why pool count and database count are independent questions
connects_to and four real connection pools
The mid-level course "Solid Queue: job architecture" looked at eleven tables: solid_queue_jobs, its claims, its concurrency rows. None of them is reached through ApplicationRecord. They sit behind SolidQueue::Record, a different base class on a different connection. This lesson looks at that…
Read the full lesson free →Curriculum
7 lessonsconnects_to and four real connection pools
Shows that Solid Queue, Solid Cache and Solid Cable use their own connects_to, creating four separate connection pools.
Dev and test: four separate physical databases
Development and test give each role its own Postgres database, which rules out cross-database joins and transactions.
Production: three roles share one database
In production, primary, queue and cable share one database, while the cache gets its own for backups and disposability.
Still four pools sharing one database: the real cost
Rails still builds one pool per role when roles share a database, which costs extra Postgres connections.
migrations_paths: how schema-load finds the right file
Explains how db:prepare loads each role's schema file and why the three migrations_paths directories do not exist yet.
Why isolate at all, if production doesn't
Compares isolation in development and test with sharing in production, and the trade-off behind each choice.
Putting it together: one connects_to, two real shapes
Separates pool count from database count and presents the ConnectsToPlanner challenge that models both questions.