← Graph

Row-Level Partitioning

concept 8 connections

Multi-tenancy implementation where each record in the database has an assigned tenant_id and queries are always scoped to the current tenant. Typically slightly denormalized — the tenant_id is duplicated onto child tables (e.g. users and tasks both carry tenant_id) to keep queries simple. Implemented in Rails with default_scope on models plus a per-request Singleton (ActiveSupport::CurrentAttributes, RequestStore, or a Rack middleware) that stores the current tenant on Thread.current. Advantages: pure Rails, no special infrastructure, no deployment impact, very low tenant-creation overhead (just insert a row) — ideal when tenants are many and low-value. Caveat: fails by leaking by default if a where-clause is forgotten; uniqueness validations must also be scoped by tenant. Existing gems (acts_as_tenant, activerecord-multi-tenant) encapsulate this behaviour.

category
pattern
about
Row-Level Partitioning concept
First of three partitioning levels covered.
about
Row-Level Partitioning concept
Recommends row-level as the default approach.
about
Row-Level Partitioning concept
Question compares partitioning approaches for cross-tenant aggregation.
about
Row-Level Partitioning concept
Performance follow-up to the row-level approach.
related_to
Row-Level Partitioning concept
Gem implements the row-level partitioning pattern.
related_to
Row-Level Partitioning concept
Gem implements the row-level partitioning pattern.
concept Row-Level Partitioning
uses
Row-level multi-tenancy stores current tenant via a per-request Singleton such as CurrentAttributes.
concept Row-Level Partitioning
uses
Older implementations use RequestStore for the per-request current tenant.

Provenance

Read by
2 extractions