Multi-Tenant vs Single-Tenant | Volba správné SaaS architektury

Každý SaaS produkt musí odpovědět na zásadní otázku: jak obsluhovat více zákazníků z jednoho softwaru? Odpověď je váš model tenancy. Ovlivňuje náklady, bezpečnost, výkon a rychlost dodávání. Správný výběr na začátku vás ochrání před bolestivými migracemi později.

Definice

Multi-tenant

Jedna instance aplikace obsluhuje všechny zákazníky. Všichni sdílejí stejné servery, stejnou kódovou základnu a často stejnou databázi. Data každého zákazníka jsou logicky izolována, ale infrastruktura je sdílená.

Představte si to jako bytový dům. Každý nájemník bydlí ve stejné budově, sdílí výtah a chodby, ale má svůj zamčený byt s vlastním nábytkem.

Single-tenant

Každý zákazník dostane svou vlastní dedikovanou instanci aplikace. Oddělené servery, oddělené databáze, někdy oddělené kódové základny. Mezi zákazníky se nesdílí nic.

Představte si to jako samostatné domy. Každý nájemník má svou vlastní budovu, své vlastní potrubí, svou vlastní zahradu. Kompletní izolace, ale dražší na údržbu.

Jak multi-tenancy funguje

Existují tři běžné přístupy k multi-tenant architektuře, každý s odlišnými kompromisy.

Model 1: Sdílená aplikace, sdílená databáze

Všichni tenanti sdílejí jednu instanci aplikace a jednu databázi. Data tenantů jsou oddělena pomocí identifikátoru tenanta (obvykle sloupec tenant_id) v každé tabulce.

Architektura:

• Jeden aplikační server (nebo cluster) zpracovává všechny požadavky.
• Jedna databáze ukládá data všech tenantů.
• Každý dotaz obsahuje klauzuli WHERE tenant_id = ? pro omezení dat na správného tenanta.

Výhody:

• Nejnižší náklady na infrastrukturu. Jedna databáze, jedno nasazení aplikace.
• Nejjednodušší nasazení a aktualizace. Pushnete jednou, všichni dostanou změnu.
• Snadná agregace dat napříč tenanty pro analytiku a reporting.

Nevýhody:

• Nejvyšší riziko úniku dat, pokud dotaz zapomene na filtr tenanta.
• Jeden hlučný tenant může degradovat výkon pro všechny ostatní.
• Databázové migrace ovlivňují všechny tenanty současně.
• Nejtěžší soulad s požadavky na rezidenci dat.

Toto je nejběžnější přístup pro B2B SaaS produkty s velkým počtem malých až středních zákazníků.

Model 2: Sdílená aplikace, oddělené databáze

Všichni tenanti sdílejí stejnou instanci aplikace, ale každý tenant má svou vlastní databázi. Aplikace směruje dotazy na správnou databázi na základě autentizovaného tenanta.

Architektura:

• Jeden aplikační server (nebo cluster) zpracovává všechny požadavky.
• Oddělená databáze pro každého tenanta.
• Směrovací vrstva mapuje identitu tenanta na správné databázové připojení.

Výhody:

• Silnější izolace dat. Žádné riziko cross-tenant dotazů.
• Snazší splnění požadavků na rezidenci dat. Každou databázi můžete umístit do regionu požadovaného tenantem.
• Záloha a obnova po tenantech je přímočará.
• Těžké využití jednoho tenanta nezamkne tabulky pro ostatní tenanty.

Nevýhody:

• Více infrastruktury ke správě. Stovky tenantů znamená stovky databází.
• Migrace schémat musí být aplikovány na každou databázi jednotlivě.
• Cross-tenant reporting vyžaduje dotazování více databází.
• Vyšší náklady než plně sdílený model.

Toto je silný střední bod pro produkty, které potřebují lepší izolaci bez nákladů plné single-tenancy.

Model 3: Oddělená aplikace, oddělená databáze

Každý tenant dostane svou vlastní instanci aplikace a svou vlastní databázi. Plně izolováno. Toto je v podstatě single-tenancy, ale spravovaná poskytovatelem SaaS místo zákazníkem.

Architektura:

• Dedikované nasazení aplikace na tenanta.
• Dedikovaná databáze na tenanta.
• Směrovací vrstva (často load balancer nebo API gateway) směruje provoz na správnou instanci.

Výhody:

• Kompletní izolace. Žádné sdílené zdroje mezi tenanty.
• Maximální flexibilita pro přizpůsobení na tenanta.
• Výkon jednoho tenanta nikdy neovlivní jiného.
• Nejjednodušší příběh souladu s předpisy.

Nevýhody:

• Nejvyšší náklady na infrastrukturu zdaleka.
• Složitost nasazení roste lineárně s počtem tenantů.
• Aktualizace musí být nasazeny na každou instanci jednotlivě (nebo velmi pečlivě automatizovány).
• Neškáluje ekonomicky pro velké počty malých tenantů.

Tento model dává smysl pro enterprise SaaS, kde zákazníci vyžadují dedikovanou infrastrukturu a jsou ochotni za ni zaplatit prémii.

Výhody a nevýhody v přehledu

Faktor	Multi-Tenant (sdílená DB)	Multi-Tenant (oddělená DB)	Single-Tenant
Náklady na infrastrukturu	Nejnižší	Střední	Nejvyšší
Izolace dat	Logická (na úrovni řádků)	Fyzická (na úrovni databáze)	Kompletní
Složitost nasazení	Nízká	Střední	Vysoká
Rychlost aktualizací	Okamžitě pro všechny	Okamžitá app, migrace per-DB	Nasazení per-instance
Přizpůsobení	Omezené	Omezené	Plné
Soulad s předpisy	Těžší	Střední	Nejsnazší
Škálovatelnost (počet tenantů)	Výborná	Dobrá	Slabá
Riziko hlučného souseda	Vysoké	Střední	Žádné

Izolace dat a bezpečnost

Izolace dat je nejdůležitější aspekt jakéhokoli modelu tenancy. Bezpečnostní únik, kdy jeden tenant může přistupovat k datům jiného tenanta, je pro SaaS byznys katastrofální. Může zničit důvěru, porušit regulace a ukončit firmu.

Row-level security

Ve sdíleném databázovém modelu je PostgreSQL Row-Level Security (RLS) jednou z nejsilnějších obran proti úniku dat. RLS vynucuje izolaci tenantů na úrovni databáze, ne na úrovni aplikace. I když má váš aplikační kód chybu, která zapomene filtrovat podle tenanta, databáze sama zabrání cross-tenant přístupu.

Zde je, jak to nastavit:

-- Enable RLS on a table
ALTER TABLE projects ENABLE ROW LEVEL SECURITY;

-- Create a policy that restricts access to the current tenant
CREATE POLICY tenant_isolation ON projects
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);

-- Force RLS even for table owners
ALTER TABLE projects FORCE ROW LEVEL SECURITY;

Před provedením jakéhokoli dotazu nastavte kontext tenanta:

-- Set at the beginning of each request/transaction
SET LOCAL app.current_tenant_id = 'a1b2c3d4-e5f6-7890-abcd-ef1234567890';

-- Now this query automatically returns only the current tenant's data
SELECT * FROM projects;
-- No WHERE clause needed. RLS handles it.

Izolace na úrovni aplikace

Kromě zabezpečení na úrovni databáze by vaše aplikace měla vynucovat hranice tenantů:

// Middleware that sets tenant context on every request
async function tenantMiddleware(req: Request, res: Response, next: NextFunction) {
  const tenantId = extractTenantId(req); // From JWT, subdomain, or header

  if (!tenantId) {
    return res.status(401).json({ error: "Tenant not identified" });
  }

  // Set tenant context for the database connection
  await db.raw(`SET LOCAL app.current_tenant_id = '${tenantId}'`);

  req.tenantId = tenantId;
  next();
}

Obrana do hloubky je zde principem. Nikdy se nespoléhejte na jedinou vrstvu izolace. Kombinujte filtrování na úrovni aplikace, zabezpečení na úrovni databáze a pravidelné bezpečnostní audity.

Výkonnostní aspekty

Výzvy sdílené databáze

Ve sdílené databázi všichni tenanti soutěží o stejné zdroje. Tenant spouštějící těžký report může zpomalit dotazy pro všechny ostatní. Zmírnění zahrnuje:

• Connection pooling. Použijte PgBouncer nebo podobný nástroj, abyste zabránili jednomu tenantovi vyčerpat databázová připojení.
• Timeouty dotazů. Nastavte maximální časy provedení, aby nezkrotný dotaz nemohl zamknout zdroje na neurčito.
• Rate limiting. Vynuťte limity per-tenant na API požadavky a databázové operace.
• Read repliky. Směrujte těžké čtecí operace (reporty, exporty) na repliku, aby neovlivňovaly primární databázi.

Výhody oddělené databáze

S per-tenant databázemi je izolace výkonu zabudovaná. Těžká zátěž jednoho tenanta ovlivňuje pouze jeho vlastní databázi. Můžete také zřídit větší nebo menší databáze na základě plánu a využití každého tenanta.

Kompromisem je režie správy. Monitorování 500 databází je těžší než monitorování jedné. Automatizované nástroje se stávají nezbytností.

Nákladové dopady ve velkém měřítku

Podívejme se na přibližná čísla. Předpokládejme, že máte 100 tenantů.

Sdílená databáze (multi-tenant):

• 1 aplikační cluster: ~200 €/měsíc
• 1 managed PostgreSQL instance: ~100 €/měsíc
• Celkem: ~300 €/měsíc (3 € na tenanta)

Oddělené databáze (multi-tenant):

• 1 aplikační cluster: ~200 €/měsíc
• 100 malých databázových instancí: ~2 000 €/měsíc
• Celkem: ~2 200 €/měsíc (22 € na tenanta)

Single-tenant:

• 100 aplikačních instancí: ~5 000 €/měsíc
• 100 databázových instancí: ~2 000 €/měsíc
• Celkem: ~7 000 €/měsíc (70 € na tenanta)

Tato čísla jsou zjednodušená, ale vzorec platí. Sdílená infrastruktura je dramaticky levnější. Při 1 000 tenantech je rozdíl ještě větší.

Proto musí ceny odpovídat architektuře. Pokud účtujete 20 € měsíčně a provozujete single-tenant infrastrukturu za 70 € na tenanta, proděláváte na každém zákazníkovi.

Kdy zvolit multi-tenant

Multi-tenant architektura je správnou volbou, když:

• Budujete B2B SaaS pro SMB. Velký objem, nižší cenové body a standardní sady funkcí.
• Záleží na nákladové efektivitě. Potřebujete udržet náklady na infrastrukturu nízké relativně k příjmům.
• Chcete rychlé, uniformní aktualizace. Nasaďte jednou, všichni tenanti dostanou vylepšení.
• Vaši zákazníci nevyžadují dedikovanou infrastrukturu. Většina malých a středních firem se nestará, kde jejich data žijí, pokud jsou v bezpečí.
• Jste v raných fázích. Začněte multi-tenant. Je to levnější a jednodušší. Single-tenant pro enterprise zákazníky můžete vždy nabídnout později.

Kdy zvolit single-tenant

Single-tenant architektura má smysl, když:

• Prodáváte enterprises. Velké organizace často vyžadují dedikovanou infrastrukturu jako součást svého nákupního procesu.
• Soulad to vyžaduje. Odvětví jako zdravotnictví (HIPAA), finance (SOX, PCI-DSS) a státní správa mají přísné požadavky na izolaci dat.
• Zákazníci potřebují přizpůsobení. Pokud každý zákazník vyžaduje odlišné konfigurace, integrace nebo dokonce funkce, single-tenant vám dává flexibilitu.
• Váš cenový bod to podporuje. Pokud účtujete 5 000 € nebo více měsíčně na zákazníka, náklady na infrastrukturu jsou snadno ospravedlnitelné.
• Rezidence dat je tvrdý požadavek. Když data musí zůstat v konkrétní zemi, oddělená infrastruktura na tenanta je nejpřímějším přístupem.

Hybridní přístupy

Nemusíte si vybrat jen jeden. Mnoho úspěšných SaaS firem používá hybridní model:

• Multi-tenant pro standardní úrovně. Zákazníci na bezplatném, starter a pro plánu sdílejí infrastrukturu. To udržuje náklady nízko a umožňuje škálování.
• Single-tenant pro enterprise. Prémioví zákazníci dostávají dedikované instance s vlastními SLA, certifikacemi souladu a dedikovanou podporou.

Aplikační kód je stejný. Model nasazení se liší. To vyžaduje dobrou automatizaci infrastruktury, ale je to prověřený vzorec.

Jak implementovat hybridní model

1. Budujte aplikaci nejprve jako multi-tenant. Veškerá logika izolace tenantů zůstává stejná bez ohledu na model nasazení.
2. Používejte infrastructure-as-code (Terraform, Pulumi nebo CDK) k automatizaci vytváření prostředí.
3. Vytvořte provisioning pipeline, která dokáže spustit nové dedikované prostředí za minuty, ne dny.
4. Udržujte jednu kódovou základnu. Stejný Docker image běží ve sdíleném i dedikovaném prostředí. Konfigurace (ne kód) určuje chování.

Databázové strategie v detailu

Databáze je místo, kde mají rozhodnutí o tenancy největší dopad. Zde jsou tři prověřené strategie.

Strategie 1: Sdílené tabulky s tenant_id

Každá tabulka má sloupec tenant_id. Všechny dotazy podle něj filtrují.

CREATE TABLE projects (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id),
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

CREATE INDEX idx_projects_tenant ON projects(tenant_id);

-- Always query with tenant context
SELECT * FROM projects WHERE tenant_id = $1;

Nejlepší pro: Většinu SaaS produktů. Jednoduché, nákladově efektivní, dobře pochopené.

Strategie 2: Schéma na tenanta

Každý tenant dostane své vlastní PostgreSQL schéma v rámci sdílené databáze. Tabulky mají stejnou strukturu, ale data jsou fyzicky oddělena.

-- Create a schema for a new tenant
CREATE SCHEMA tenant_abc123;

-- Create tables in the tenant's schema
CREATE TABLE tenant_abc123.projects (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Set the search path per request
SET search_path TO tenant_abc123, public;

-- Now queries are automatically scoped
SELECT * FROM projects;

Nejlepší pro: Produkty potřebující silnější izolaci než na úrovni řádků, ale nechcete náklady oddělených databází. Funguje dobře do několika stovek tenantů.

Strategie 3: Oddělené databáze

Každý tenant dostane dedikovanou PostgreSQL instanci (nebo dedikovanou databázi na sdíleném serveru).

// Database connection routing
class TenantDatabaseRouter {
  private connections: Map<string, DatabasePool> = new Map();

  async getConnection(tenantId: string): Promise<DatabasePool> {
    if (this.connections.has(tenantId)) {
      return this.connections.get(tenantId)!;
    }

    const config = await this.loadTenantDbConfig(tenantId);
    const pool = new DatabasePool({
      host: config.host,
      port: config.port,
      database: config.database,
      user: config.user,
      password: config.password,
    });

    this.connections.set(tenantId, pool);
    return pool;
  }

  private async loadTenantDbConfig(tenantId: string): Promise<DbConfig> {
    // Look up tenant's database connection details
    // from a central configuration store
    return await configStore.get(`tenants/${tenantId}/database`);
  }
}

Nejlepší pro: Enterprise SaaS s vysoce hodnotnými zákazníky, přísnými požadavky na soulad nebo povinnostmi rezidence dat.

Rozhodování

Zde je jednoduchý rozhodovací framework:

1. Jaká je velikost vašich cílových zákazníků? SMB ukazuje na multi-tenant. Enterprise ukazuje na single-tenant nebo hybrid.
2. Jaký je váš cenový bod? Pod 100 €/měsíc potřebujete multi-tenant, abyste byli profitabilní. Nad 1 000 €/měsíc se single-tenant stává životaschopným.
3. Jaké jsou požadavky na soulad? Regulovaná odvětví často vyžadují silnější izolaci.
4. Kolik tenantů očekáváte? Stovky nebo tisíce tenantů potřebují sdílenou infrastrukturu. Deset až padesát velkých tenantů může fungovat s dedikovanými instancemi.
5. Jaká je provozní kapacita vašeho týmu? Single-tenant vyžaduje větší investice do DevOps. Multi-tenant je provozně jednodušší.

Pokud si nejste jisti, začněte s multi-tenant se sdílenou databází a row-level security. Je to možnost s nejnižšími náklady, je bezpečná při správné implementaci a udržuje vaši architekturu jednoduchou. Dedikovanou úroveň pro enterprise zákazníky můžete vždy přidat později.

Závěr

Neexistuje univerzálně správný model tenancy. Správná volba závisí na vašich zákaznících, vašich cenách, vašich požadavcích na soulad a vašich provozních schopnostech.

Většina SaaS produktů by měla začít multi-tenant. Je to levnější, jednodušší a dobře škáluje. Jak se posunete na vyšší trh a začnete prodávat větším organizacím, přidejte single-tenant možnosti pro zákazníky, kteří je potřebují a zaplatí za ně.

Architektura by měla sloužit podnikání, ne naopak. Budujte pro zákazníky, které máte dnes, a navrhujte s dostatečnou flexibilitou pro obsluhu zákazníků, které chcete zítra.

---

Potřebujete pomoc s výběrem správné architektury pro váš SaaS produkt? Budovali jsme multi-tenant i single-tenant systémy napříč odvětvími. Pojďme najít nejlepší přístup pro váš projekt.