41 million API requests per hour. 11.8 million background jobs per hour. 226,000 peak database transactions per second. That's what Aura Frames pushed through on Christmas Day 2025, powered by a Ruby on Rails codebase split across 8 primary PostgreSQL databases. The secret weapon: disable_joins: true.
Before this rewrite, a single jumbo RDS instance (192 vCPU, 1.5 TB RAM) had hit reliability limits during Christmas 2024. The team knew vertical scaling wasn't going to cut it again. They needed horizontal write scaling without rewriting everything.
How 8 Databases Beat the Christmas Peak
Aura Frames split from a single primary database into 8 primaries, each running in its own RDS instance. The application layer controls shard routing, not the database. Rails' built-in multiple database support plus the disable_joins: true option made this practical.
That option replaces SQL JOINs with multiple SELECT statements, fetching associated data from separate databases and combining them in application memory. No cross-database queries, no schema coupling. The development environment keeps all 8 databases inside a single Docker Postgres container, so any accidental cross-database query breaks immediately in tests.
The payoff came on December 25: peak load at 1pm CT hit 41M requests/hour. Average response time stayed at 650 milliseconds across the 11-hour peak window. The free Aura Frames app hit #1 in both the U.S. and Canadian Apple App Stores, beating ChatGPT and Meta AI.
The disable_joins: true Tactic
When you split tables across databases, ActiveRecord associations that normally fire a JOIN will fail. disable_joins: true tells Rails to issue two queries instead: one to get the foreign keys, another to fetch the associated records. It's slower per association but eliminates the single point of failure that a cross-database JOIN creates.
Aura Frames applied this to has_many, has_one, has_and_belongs_to_many, and other association types. They also reworked aggregations to use subqueries and EXISTS clauses that stay within a single database. Counter caches need careful maintenance across shards. Random sampling and paginated reads now use batching to avoid hammering any one primary.
What It Took to Get There
Heavy refactoring hit the Active Record query layer. Every query that spanned a database boundary had to be rewritten. But the team kept the same schema across all 8 primaries: no row-level sharding, just database-level sharding with symmetric schemas.
Schema changes run against each primary in sequence. Rails' migration tooling handles this natively. The team vertically scales each instance up before peaks, then back down to save costs. No single bottleneck, no 48x instance needed.
The real metric that matters: 11:30 PM on Christmas Day, the app reached #1 in the App Store. That's what 8 databases and a disable_joins flag buy you when your users are uploading photos to their digital frames faster than you can count.
Source: Scaling Rails: 41M Req/Hour, 8 DBs, disable_joins: true
Domain: andyatkinson.com
Comments load interactively on the live page.