Introduction

The talk, delivered by Mike Dalessio at Rails World 2025, explores approaches to multi-tenancy in Rails applications, focusing on achieving strict data isolation by giving each tenant (customer) their own database. The key showcase is the new open-source gem 'activerecordtenanted' from 37signals, designed to provide comprehensive, production-ready multi-tenancy support in Rails, particularly leveraging SQLite's improvements.

Key Points

• Multi-Tenancy Models in Rails

  • Two typical models: co-mingled data (single database, tenant_id per row) vs. separate databases (distinct database/schema per tenant).
  • Co-mingled data (via gems like actsastenant) places responsibility on application code; prone to accidental data leaks if tenant_id is missed.
  • Separate databases provide stronger isolation and are safer but require more infrastructure and connection management.

• Existing Solutions and Limitations

  • Gems like apartment (2011) use separate databases but lack modern thread-safe connection handling and comprehensive Rails integration.
  • Rails 6.1 introduced horizontal sharding and multi-database support with thread safety, but out-of-the-box Rails requires static shard configuration and is not dynamic, making large-scale tenancy cumbersome.

• Motivation for a New Approach

  • Need for dynamic, thread-safe, scalable tenant connection management.
  • Desire for seamless integration across all Rails features: not just ActiveRecord, but also fragment caching, background jobs, Active Storage, Action Cable, Turbo Streams, Action Mailer, and testing.

• The activerecordtenanted Gem

  • Designed for simplicity: By default, all models inheriting from ApplicationRecord are tenanted.
  • Tenant resolution is typically based on the request subdomain, with flexibility to customize.
  • Migrating an app from single-tenant to multi-tenant can be as easy as three code changes: adding the gem, annotating ApplicationRecord, and modifying the database.yml to use a per-tenant path.
  • Focus initially on SQLite but with potential for PostgreSQL/MySQL support.

• Technical Deep Dive

  • The gem leverages Rails' registerdbconfig_handler to dynamically generate configurations per tenant at runtime, avoiding static definitions.
  • It manages connection pools per tenant, creates them on first access, and ensures tenant-aware access throughout the stack.
  • Provides API for tenant management (listing, checking, creating tenants; context blocks for tenant-specific operations).
  • Implements strong safety guarantees—attempts to access or update data outside the correct tenant context raise errors.

• Integrations Across the Rails Ecosystem

  • Handles Rails records (e.g., those used by ActionText, ActiveStorage) with 'subtenant_of' to ensure correct tenant context for joins.
  • Ensures fragment caches, cache keys, and storage blobs are tenant-isolated—uses the tenant id in keys and storage paths.
  • Background jobs (ActiveJob) and GlobalID serialization handle tenant context; jobs can't accidentally operate in the wrong tenant context.
  • ActionCable, Turbo Streams, ActionMailer, and test helpers all hook into the same tenancy management.

• Performance and Edge Cases

  • Demonstrated capability to handle large numbers of tenants and databases efficiently with SQLite.
  • Identified potential scaling issues (large connection pools), with a roadmap to cap/reap pools.
  • Ongoing work on database task integrations before 1.0 release.

Conclusion & Takeaways

• The new gem, activerecordtenanted, provides a robust, framework-level solution to multi-tenancy with a focus on secure data isolation and seamless Rails integration.
• The approach minimizes application code complexity, reduces risk of data leakage, and supports modern, scalable Rails apps.
• The gem is now open-source and invites community feedback and contributions, especially for broader database support and scalability improvements.