Simeon Griggs [@simeonGriggs] | April 21, 2026NoteWe've updated our use of the term "row-level isolation" to "shared-schema" in this article to avoid confusion with Postgres RLS. We do not recommend relying on Postgres RLS.Multi-tenancy is a term used across various kinds of technical infrastructure, including application hosting, compute, databases, and more.For example, you may purchase cloud services from a provider, but your account is one of many that draws from a common pool of resources. Your account is one "tenant" in a multi-tenant infrastructure.In this article, we're focusing on using a single Postgres database cluster to serve an application with many tenants—you are our customer, and your customers are tenants in that cluster.Given the many approaches to multi-tenancy within a Postgres database, it is worth clarifying the recommended best practices and the data models you should avoid. These recommendations are informed by years of seeing multi-tenant applications, both good and bad, succeed and fail at scale.DefinitionsThe term "database" is overloaded and can refer to different things:A Database Cluster refers to the entire database server instance – the running Postgres process, its storage and any replicas.A Logical Database is an isolated namespace within a database cluster that contains its own schemas, tables, and data.When you generate credentials to connect to a database, you're connecting to the database cluster. The queries you perform will target a single logical database within it. On PlanetScale Postgres, the default logical database name is postgres.In short: one database cluster can contain many logical databases.When modeling data in a relational database:A Tenant refers to a single entity that accesses their own subset of data in your application.Single-tenancy refers to giving each tenant their own isolated schema, logical database, or database cluster.Multi-tenancy refers to using a consistent schema (set of tables and relationships) for all of the users of your application within a single database cluster.Three approaches to tenant isolationThere are three common approaches to separating tenant data within a single database cluster:Shared-schema where each user/tenant uses a shared set of tables and is isolated by a column value such as user_id, tenant_id, etc.Schema-per-tenant where each tenant has its own schema and tablesDatabase-per-tenant where each tenant has its own logical database, schema, and tablesOf the three approaches, shared-schema is the most common and is our recommended approach.Shared-schema is also the only true method of "multi-tenancy" in a relational database. Schema-per-tenant and database-per-tenant within the same database cluster do not share tables, but they do share resources.Finally, you may already be running a database using one schema-per-tenant. You may be able to migrate to a recommended approach to improve the performance of your application and workloads. See Migrating to schared-schema multi-tenancy.Good examples for multi-tenancyGood examples of multi-tenancy include SaaS applications that need to isolate data for each customer but have so many customers that it would be impractical to assign each customer to an individual database cluster. Or multi-national applications that need to isolate data for each country, market, or region.These are good use cases for multi-tenancy because only the data is different between tenants. The schema, tables, relationships, application code and access patterns are uniform across all tenants.With any multi-tenancy approach, your goal should be for data belonging to each tenant to be consumed by the same applications, with care to ensure that one tenant cannot query another tenant's data nor that their behavior in your application could jeopardize the experience of another tenant.NoteThese recommendations assume all tenants share the same schema. If tenants genuinely need different schema structures, schema-per-tenant or database-per-tenant is the better fit.Recommended. This is the most common, general-purpose method for combining tenants in a single database.All data is stored in a single database clusterAll tenants share the same schema and tablesEach tenant's data is isolated with a column such as tenant_idWith shared-schema, each tenant shares the same schema and tables, but has its own data.This is the simplest model conceptually and the most scalable approach to multi-tenancy.CREATE TABLE orders (