0Pricing
FastAPI Backend Development Bootcamp · Pelajaran

Strategi Isolasi Penyewa dan Konsekuensinya

Bandingkan model isolasi skema bersama, skema per penyewa, dan basis data per penyewa untuk beban kerja SaaS.

Strategi Isolasi Penyewa dan Konsekuensinya adalah pelajaran FastAPI Backend Development Bootcamp gratis di CoddyKit. Ini adalah pelajaran 1 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar FastAPI Backend Development Bootcamp, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus FastAPI Backend Development Bootcamp mencakup 4 pelajaran total.

Bagian dari pelajaran ini belum diterjemahkan dan ditampilkan dalam bahasa Inggris.

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.

Pertanyaan yang Sering Diajukan

Apakah pelajaran “Strategi Isolasi Penyewa dan Konsekuensinya” gratis?

Ya — teks lengkap “Strategi Isolasi Penyewa dan Konsekuensinya” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus FastAPI Backend Development Bootcamp, upgrade ke CoddyKit PRO. Kursus FastAPI Backend Development Bootcamp mencakup 4 pelajaran total.

Apa yang akan aku pelajari di “Strategi Isolasi Penyewa dan Konsekuensinya”?

Bandingkan model isolasi skema bersama, skema per penyewa, dan basis data per penyewa untuk beban kerja SaaS. Kamu berlatih FastAPI Backend Development Bootcamp dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.

Apakah aku perlu pengalaman untuk memulai FastAPI Backend Development Bootcamp?

Tidak diperlukan pengalaman sebelumnya. FastAPI Backend Development Bootcamp di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 1 dari 4.

Berapa lama pelajaran “Strategi Isolasi Penyewa dan Konsekuensinya” memakan waktu?

Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.

Bisakah aku menulis dan menjalankan kode dalam pelajaran FastAPI Backend Development Bootcamp ini?

Ya. Setiap pelajaran FastAPI Backend Development Bootcamp menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.

Semua pelajaran dalam kursus ini

  1. Strategi Isolasi Penyewa dan Konsekuensinya
  2. Resolusi Konteks Penyewa dan Middleware
  3. Keamanan Tingkat Baris dan Pemartisian Data
  4. Pengukuran Penggunaan, Kuota, dan Kait Penagihan
← Kembali ke FastAPI Backend Development Bootcamp