0Pricing
FastAPI Backend Development Bootcamp · 课时

租户隔离策略与权衡

比较共享模式、每租户独立模式和每租户独立数据库等 SaaS 工作负载隔离模型。

租户隔离策略与权衡 是 CoddyKit 上的免费 FastAPI Backend Development Bootcamp 课时。 这是第 1 节课，共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 FastAPI Backend Development Bootcamp 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 FastAPI Backend Development Bootcamp 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

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.

常见问题解答

「租户隔离策略与权衡」课时是免费的吗？

是的 — 「租户隔离策略与权衡」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 FastAPI Backend Development Bootcamp 课程的其余内容，请升级到 CoddyKit PRO。 FastAPI Backend Development Bootcamp 课程共包含 4 节课。

「租户隔离策略与权衡」这节课中我会学到什么？

比较共享模式、每租户独立模式和每租户独立数据库等 SaaS 工作负载隔离模型。 你通过在浏览器中直接运行的动手代码来练习 FastAPI Backend Development Bootcamp，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 FastAPI Backend Development Bootcamp 需要有经验吗？

无需任何先前经验。CoddyKit 上的 FastAPI Backend Development Bootcamp 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。 这是第 1 节课，共 4 节。

「租户隔离策略与权衡」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 FastAPI Backend Development Bootcamp 课中编写并运行代码吗？

能。每节 FastAPI Backend Development Bootcamp 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

  1. 租户隔离策略与权衡
  2. 租户上下文解析与中间件
  3. 行级安全与数据分区
  4. 用量计量、配额与计费钩子
← 返回 FastAPI Backend Development Bootcamp