// the find
thiagopradi/octopus
Database Sharding for ActiveRecord
Octopus adds database sharding and read replica routing to ActiveRecord via a proxy layer that intercepts queries and routes them to the right connection. It targets Rails apps that need to split data across multiple databases before Rails had native support for this. It's effectively a historical artifact — Rails 6 shipped multi-db support natively, and the README says so upfront.
The API is clean for what it does: `using(:shard)` on any AR relation or wrapped in a block covers most routing needs without requiring model-level changes. Migration support is non-trivial and actually works — running the same migration across specific shards or groups is handled without forking the migration system. The proxy architecture means most AR code doesn't need to know about shards at all, which is the right abstraction level. Test suite covers MySQL, PostgreSQL, and SQLite across multiple Rails versions via Appraisals, which is a real commitment for a library this complex.
This is maintenance-mode software targeting Rails 4/5, and Rails 6+ has native horizontal sharding — you should not be starting a new project with Octopus in 2024. The proxy approach is inherently fragile: it patches deep into ActiveRecord internals and breaks in subtle ways across AR versions (the long rubocop_todo file and the version-specific gemfiles are evidence of the ongoing whack-a-mole). There is no automatic shard selection by key — you have to manually route every query, which means shard logic bleeds into application code. The promised 'Tools to manage database configurations' is still marked 'soon' in the README, suggesting development stalled well before reaching feature completeness.