FastAPI Backend Development Bootcamp · Lesson

Tenant Isolation Strategies and Trade-offs

Compare shared-schema, schema-per-tenant, and database-per-tenant isolation models for SaaS workloads.

Tenant Isolation Strategies and Trade-offs is a free FastAPI Backend Development Bootcamp lesson on CoddyKit — lesson 1 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the FastAPI Backend Development Bootcamp learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Why Tenant Isolation Matters

In a multi-tenant SaaS, many customers (tenants) share one running FastAPI application. The central question is: how isolated is each tenant's data?

Isolation affects four things you must trade off constantly:

Security & blast radius — can a bug leak Tenant A's rows to Tenant B?
Cost — how much infra does each tenant consume?
Operational complexity — migrations, backups, restores.
Per-tenant customization — can one tenant get extra columns or a custom schema?

Three canonical models exist: shared-schema, schema-per-tenant, and database-per-tenant. The rest of this lesson compares them for FastAPI workloads.

Shared-Schema: One Table, a tenant_id Column

The simplest model: every tenant's rows live in the same tables, distinguished by a tenant_id column. Every query must filter on it.

This is the cheapest and most scalable option for thousands of small tenants, but isolation is purely logical — one missing WHERE tenant_id = ... leaks data across tenants.

Below is the typical SQLAlchemy model shape. Note the indexed tenant_id on every tenant-owned table.

from sqlalchemy import String, Integer, ForeignKey, Index
from sqlalchemy.orm import DeclarativeBase, Mapped, mapped_column

class Base(DeclarativeBase):
    pass

class Invoice(Base):
    __tablename__ = "invoices"
    id: Mapped[int] = mapped_column(primary_key=True)
    tenant_id: Mapped[str] = mapped_column(String, index=True)
    amount_cents: Mapped[int] = mapped_column(Integer)
    customer_email: Mapped[str] = mapped_column(String)

    # Composite index: nearly every query filters by tenant first
    __table_args__ = (Index("ix_invoices_tenant_id", "tenant_id"),)

Resolving the Tenant from the Request

Before any query runs, you must know which tenant the request belongs to. Common strategies:

Subdomain — acme.app.com → tenant acme.
JWT claim — the access token carries a tenant_id.
Header — X-Tenant-ID (internal/service-to-service).

In FastAPI this becomes a dependency that resolves and validates the tenant once, then injects it everywhere. Never trust a tenant id the client can freely set unless it is cryptographically bound (e.g. inside a signed JWT).

from fastapi import Depends, HTTPException, Request

async def get_current_tenant(request: Request) -> str:
    host = request.headers.get("host", "")
    sub = host.split(".")[0]
    if not sub or sub in {"www", "app"}:
        raise HTTPException(status_code=400, detail="Tenant could not be resolved")
    return sub

# Usage in a route:
# @app.get("/invoices")
# async def list_invoices(tenant_id: str = Depends(get_current_tenant)):
#     ...

The Shared-Schema Danger: Forgetting the Filter

The #1 risk in shared-schema is a developer forgetting WHERE tenant_id = :tenant. The query still succeeds — it just returns everyone's data.

Two defenses scale better than discipline:

A repository layer that always injects tenant_id, so route code can't issue a raw unscoped query.
Postgres Row-Level Security (RLS) as a database-enforced backstop (covered next).

Here a thin repository guarantees scoping at the application layer.

from sqlalchemy import select
from sqlalchemy.ext.asyncio import AsyncSession

class InvoiceRepository:
    def __init__(self, session: AsyncSession, tenant_id: str):
        self.session = session
        self.tenant_id = tenant_id

    async def list(self):
        # tenant_id is ALWAYS applied — callers cannot bypass it
        stmt = select(Invoice).where(Invoice.tenant_id == self.tenant_id)
        result = await self.session.execute(stmt)
        return result.scalars().all()

    async def get(self, invoice_id: int):
        stmt = select(Invoice).where(
            Invoice.id == invoice_id,
            Invoice.tenant_id == self.tenant_id,
        )
        return (await self.session.execute(stmt)).scalar_one_or_none()

Database-Enforced Isolation with Postgres RLS

Row-Level Security lets Postgres itself reject rows that don't match the current tenant — even if the app forgets the filter. You set a session variable per request and the policy uses it.

This turns shared-schema from "hope the WHERE is there" into "the database guarantees it." The trade-off: every connection must set the variable, which interacts carefully with connection pooling (set it per-transaction).

-- One-time DDL
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON invoices
  USING (tenant_id = current_setting('app.current_tenant', true));

-- Per request / per transaction, the app runs:
-- SET LOCAL app.current_tenant = 'acme';
-- Now SELECT * FROM invoices only returns acme's rows automatically.

Wiring RLS into a FastAPI Request

To make RLS work, each request opens a transaction, issues SET LOCAL app.current_tenant, then runs all queries inside it. SET LOCAL is scoped to the transaction, so a pooled connection won't leak the value to the next tenant.

This pattern combines an application dependency (resolve tenant) with database enforcement (RLS policy) — defense in depth.

from sqlalchemy import text
from sqlalchemy.ext.asyncio import AsyncSession

async def tenant_session(
    tenant_id: str = Depends(get_current_tenant),
) -> AsyncSession:
    async with SessionLocal() as session:
        async with session.begin():
            # bind param avoids SQL injection of the tenant value
            await session.execute(
                text("SET LOCAL app.current_tenant = :t"),
                {"t": tenant_id},
            )
            yield session

Schema-per-Tenant: Same DB, Separate Namespaces

In schema-per-tenant, one Postgres database holds many schemas — tenant_acme.invoices, tenant_globex.invoices. Tables are identical but physically separated by schema.

Pros: stronger isolation than shared-schema, no tenant_id column needed, per-tenant backup/restore is easier, and you can drop a tenant by dropping a schema.

Cons: migrations must run across every schema (N times), and Postgres degrades with very high schema/table counts (thousands of schemas bloat the catalog). Best for tens to low-hundreds of larger tenants.

Routing Queries by Schema (search_path)

Postgres resolves unqualified table names using the search_path. Per request, you set it to the tenant's schema, and the same ORM models now read/write that tenant's tables.

As with RLS, use SET LOCAL search_path inside a transaction so a pooled connection never carries one tenant's schema into another tenant's request.

from sqlalchemy import text

async def schema_scoped_session(
    tenant_id: str = Depends(get_current_tenant),
):
    schema = f"tenant_{tenant_id}"
    async with SessionLocal() as session:
        async with session.begin():
            # quote_ident-style guard: validate before interpolating identifiers
            if not tenant_id.isalnum():
                raise HTTPException(400, "Invalid tenant identifier")
            await session.execute(text(f'SET LOCAL search_path TO "{schema}", public'))
            yield session

Migrations Across Many Schemas

The operational tax of schema-per-tenant is migrations. A single Alembic upgrade must be applied to each tenant schema. You iterate over the tenant list, set the schema, and run the migration.

Plan for partial failure: if schema 200 of 300 fails, you need idempotent, resumable migrations. This is the main reason teams cap schema-per-tenant at hundreds, not thousands, of tenants.

# Conceptual loop run by an Alembic env.py or a management command
tenant_schemas = ["tenant_acme", "tenant_globex", "tenant_initech"]

def run_migrations_for_all(connection, run_one):
    failures = []
    for schema in tenant_schemas:
        try:
            connection.execute(f'SET search_path TO "{schema}"')
            run_one(connection)  # apply the same upgrade per schema
        except Exception as exc:  # noqa: BLE001
            failures.append((schema, str(exc)))
    if failures:
        raise RuntimeError(f"Migration failed for: {failures}")

Database-per-Tenant: Maximum Isolation

Database-per-tenant gives each tenant its own database (sometimes its own server). Isolation is the strongest possible: separate connections, separate backups, even separate regions for data-residency compliance.

Pros: hard security boundary, trivial per-tenant restore, easy "noisy neighbor" isolation, simple per-tenant data deletion (drop the DB).

Cons: highest cost and ops overhead — you maintain a connection pool per database, can't easily run cross-tenant analytics, and onboarding a tenant means provisioning a DB. Best for few, large, high-compliance tenants (e.g. enterprise B2B).

Connection Routing for Database-per-Tenant

The app keeps a registry mapping tenant → database URL and a cache of engines/pools. A dependency resolves the tenant, looks up its DSN, and hands back a session bound to that database.

Caching engines is essential: creating a new engine per request exhausts connections. Cache one engine per tenant and reuse its pool.

from functools import lru_cache
from sqlalchemy.ext.asyncio import create_async_engine, async_sessionmaker

TENANT_DSNS = {
    "acme": "postgresql+asyncpg://app@db-acme/acme",
    "globex": "postgresql+asyncpg://app@db-globex/globex",
}

@lru_cache(maxsize=256)
def engine_for(tenant_id: str):
    dsn = TENANT_DSNS.get(tenant_id)
    if dsn is None:
        raise HTTPException(404, "Unknown tenant")
    return create_async_engine(dsn, pool_size=5, max_overflow=2)

async def db_per_tenant_session(tenant_id: str = Depends(get_current_tenant)):
    maker = async_sessionmaker(engine_for(tenant_id), expire_on_commit=False)
    async with maker() as session:
        yield session

Quick Check: Choosing an Isolation Model

A B2B startup expects to onboard 5,000 small tenants in year one. They want the lowest infra cost and the simplest migration story, and they are willing to invest in strong query-scoping discipline plus a database-enforced backstop. Which isolation model fits best?

Recap: Picking the Right Isolation Strategy

Three models on a spectrum from cheap-and-shared to expensive-and-isolated:

Shared-schema — one tenant_id column. Cheapest, scales to thousands of small tenants, one migration. Risk: logical-only isolation; mitigate with a scoping repository plus RLS.
Schema-per-tenant — one schema each via search_path. Stronger isolation, easy per-tenant backup/drop. Cost: migrations run N times; caps at hundreds of tenants.
Database-per-tenant — one DB each, engine cached per tenant. Strongest isolation and data-residency control. Cost: highest ops/infra; best for few large, high-compliance tenants.

Decision drivers: tenant count and size, compliance/data-residency needs, migration tolerance, and budget. Many real systems are hybrid — shared-schema for the long tail of small customers, database-per-tenant for enterprise accounts. In FastAPI, the seam in all three is the same: a tenant-resolution dependency that injects the right session.

Frequently asked questions

Is the “Tenant Isolation Strategies and Trade-offs” lesson free?

Yes — the full text of “Tenant Isolation Strategies and Trade-offs” is free to read here on the web, and the FastAPI Backend Development Bootcamp course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the FastAPI Backend Development Bootcamp course, upgrade to CoddyKit PRO.

What will I learn in “Tenant Isolation Strategies and Trade-offs”?

Compare shared-schema, schema-per-tenant, and database-per-tenant isolation models for SaaS workloads. You practise FastAPI Backend Development Bootcamp with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start FastAPI Backend Development Bootcamp?

No prior experience is required. FastAPI Backend Development Bootcamp on CoddyKit is structured for beginners through advanced learners; this is — lesson 1 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Tenant Isolation Strategies and Trade-offs” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this FastAPI Backend Development Bootcamp lesson?

Yes. Every FastAPI Backend Development Bootcamp lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

Tenant Isolation Strategies and Trade-offs
Tenant Context Resolution and Middleware
Row-Level Security and Data Partitioning
Usage Metering, Quotas and Billing Hooks

← Back to FastAPI Backend Development Bootcamp