Nightmare neighbours caveats of Rails based mutlitenancy

Karol Szuster's wroclove.rb 2022 talk on the multi-tenant application pattern in Rails. Covers what multi-tenancy is and why we do it (quick setup, maintainability, cost), and the pivotal concern of isolating tenant data. Walks through three levels of partitioning: (1) row-level — each record has a tenant_id, implemented via default scopes and a per-request Singleton such as ActiveSupport::CurrentAttributes or RequestStore; (2) row-level hardened with Postgres row-level security (ENABLE ROW LEVEL SECURITY, policies comparing tenant_id to a session parameter, FORCE ROW LEVEL SECURITY to catch table owners), including caveats around connection pooling/session parameter reset and PgBouncer transaction pooling; (3) schema-level partitioning using the search_path session parameter (low-effort migration but custom migration process, harder backups — Heroku advises against, apartment authors soured on it); (4) database-level partitioning with a separate database per tenant — noting apartment's unsafe connection re-establishment pattern not thread-safe under Puma, and recommending Rails 6.1 horizontal sharding instead. Concludes with the Noisy Neighbor problem, application-level concerns (Sidekiq, Elasticsearch indices per tenant), and the core takeaway: decide early. Row-level is the default recommendation (Shopify, Salesforce). Q&A covers cross-tenant aggregation, the where-clause risk given acts_as_tenant's default, multi-column indexes scoped by tenant, and database views / read models per tenant.