Multi-Tenant vs Single-Tenant | Výber správnej SaaS architektúry

Každý SaaS produkt musí odpovedať na fundamentálnu otázku: ako obslúžite viacerých zákazníkov z rovnakého softvéru? Odpoveď je váš model tenancy. Ovplyvňuje náklady, bezpečnosť, výkon a rýchlosť dodávania. Správne rozhodnutie na začiatku vás ušetrí od bolestivých migrácií neskôr.

Definície

Multi-tenant

Jedna inštancia aplikácie obsluhuje všetkých zákazníkov. Všetci zdieľajú rovnaké servery, rovnakú kódovú základňu a často rovnakú databázu. Dáta každého zákazníka sú logicky izolované, ale infraštruktúra je zdieľaná.

Predstavte si to ako bytový dom. Každý nájomník žije v rovnakej budove, zdieľa výťah a chodby, ale má vlastný zamknutý byt s vlastným nábytkom.

Single-tenant

Každý zákazník dostane vlastnú dedikovanú inštanciu aplikácie. Oddelené servery, oddelené databázy, niekedy oddelené kódové základne. Medzi zákazníkmi sa nezdieľa nič.

Predstavte si to ako samostatné domy. Každý nájomník má vlastnú budovu, vlastné rozvody, vlastnú záhradu. Úplná izolácia, ale drahšia údržba.

Ako funguje multi-tenancy

Existujú tri bežné prístupy k multi-tenant architektúre, každý s rôznymi kompromismi.

Model 1: Zdieľaná aplikácia, zdieľaná databáza

Všetci tenanti zdieľajú jednu inštanciu aplikácie a jednu databázu. Dáta tenantov sú oddelené pomocou identifikátora tenanta (zvyčajne stĺpec tenant_id) v každej tabuľke.

Architektúra:

• Jeden aplikačný server (alebo cluster) spracováva všetky požiadavky.
• Jedna databáza uchováva všetky dáta tenantov.
• Každý dotaz obsahuje klauzulu WHERE tenant_id = ? na filtrovanie dát správneho tenanta.

Výhody:

• Najnižšie infraštruktúrne náklady. Jedna databáza, jedno nasadenie aplikácie.
• Najjednoduchšie nasadenie a aktualizácia. Nasaďte raz, všetci dostanú zmenu.
• Jednoduché agregovanie dát naprieč tenantmi pre analytiku a reporting.

Nevýhody:

• Najvyššie riziko úniku dát, ak dotaz zabudne filter tenanta.
• Jeden hlučný tenant môže degradovať výkon pre všetkých.
• Databázové migrácie ovplyvňujú všetkých tenantov súčasne.
• Najťažšie vyhovieť požiadavkám na rezidencii dát.

Toto je najbežnejší prístup pre B2B SaaS produkty s veľkým počtom malých až stredných zákazníkov.

Model 2: Zdieľaná aplikácia, oddelené databázy

Všetci tenanti zdieľajú rovnakú inštanciu aplikácie, ale každý tenant dostane vlastnú databázu. Aplikácia smeruje dotazy do správnej databázy na základe autentifikovaného tenanta.

Architektúra:

• Jeden aplikačný server (alebo cluster) spracováva všetky požiadavky.
• Oddelená databáza pre každého tenanta.
• Smerovacia vrstva mapuje identitu tenanta na správne databázové pripojenie.

Výhody:

• Silnejšia izolácia dát. Žiadne riziko cross-tenant dotazov.
• Jednoduchšie splnenie požiadaviek na rezidencii dát. Každú databázu môžete umiestniť do požadovaného regiónu tenanta.
• Záloha a obnova per-tenant je priamočiara.
• Vysoké zaťaženie jedného tenanta nezablokuje tabuľky pre ostatných tenantov.

Nevýhody:

• Viac infraštruktúry na správu. Stovky tenantov znamená stovky databáz.
• Schémové migrácie sa musia aplikovať na každú databázu individuálne.
• Cross-tenant reporting vyžaduje dotazovanie viacerých databáz.
• Vyššie náklady ako plne zdieľaný model.

Toto je silný stredný bod pre produkty, ktoré potrebujú lepšiu izoláciu bez nákladov plnej single-tenancy.

Model 3: Oddelená aplikácia, oddelená databáza

Každý tenant dostane vlastnú inštanciu aplikácie a vlastnú databázu. Plne izolované. Toto je v podstate single-tenancy, ale spravovaná poskytovateľom SaaS namiesto zákazníkom.

Architektúra:

• Dedikované nasadenie aplikácie per tenant.
• Dedikovaná databáza per tenant.
• Smerovacia vrstva (často load balancer alebo API gateway) smeruje prevádzku na správnu inštanciu.

Výhody:

• Úplná izolácia. Žiadne zdieľané zdroje medzi tenantmi.
• Maximálna flexibilita pre prispôsobenie per tenant.
• Výkon jedného tenanta nikdy neovplyvní iného.
• Najjednoduchší príbeh súladu.

Nevýhody:

• Najvyššie infraštruktúrne náklady.
• Zložitosť nasadenia rastie lineárne s počtom tenantov.
• Aktualizácie sa musia distribuovať na každú inštanciu individuálne (alebo veľmi opatrne automatizovať).
• Neškáluje sa ekonomicky pre veľký počet malých tenantov.

Tento model má zmysel pre enterprise SaaS, kde zákazníci vyžadujú dedikovanú infraštruktúru a sú ochotní za ňu platiť prémiu.

Výhody a nevýhody na prvý pohľad

Faktor	Multi-Tenant (zdieľaná DB)	Multi-Tenant (oddelená DB)	Single-Tenant
Infraštruktúrne náklady	Najnižšie	Stredné	Najvyššie
Izolácia dát	Logická (na úrovni riadkov)	Fyzická (na úrovni databázy)	Úplná
Zložitosť nasadenia	Nízka	Stredná	Vysoká
Rýchlosť aktualizácie	Okamžitá pre všetkých	Okamžitá app, per-DB migrácie	Per-inštancia rollout
Prispôsobenie	Obmedzené	Obmedzené	Plné
Súlad	Ťažší	Stredný	Najľahší
Škálovateľnosť (počet tenantov)	Výborná	Dobrá	Slabá
Riziko hlučného suseda	Vysoké	Stredné	Žiadne

Izolácia a bezpečnosť dát

Izolácia dát je najdôležitejšou úvahou v akomkoľvek modeli tenancy. Bezpečnostný incident, kde jeden tenant pristúpi k dátam iného tenanta, je pre SaaS biznis katastrofálny. Môže zničiť dôveru, porušiť regulácie a ukončiť firmu.

Row-level security

V modeli zdieľanej databázy je Row-Level Security (RLS) v PostgreSQL jednou z najsilnejších obrán proti úniku dát. RLS vynucuje izoláciu tenantov na úrovni databázy, nie aplikácie. Aj keď má váš aplikačný kód chybu, ktorá zabudne filtrovať podľa tenanta, databáza samotná zabraňuje cross-tenant prístupu.

Tu je, ako to nastaviť:

-- 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;

Pred vykonaním akéhokoľvek 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.

Izolácia na úrovni aplikácie

Okrem bezpečnosti na úrovni databázy by vaša aplikácia mala vynucovať hranice tenantov:

// 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 hĺbky je tu princípom. Nikdy sa nespoliehajte na jednu vrstvu izolácie. Kombinujte filtrovanie na úrovni aplikácie, bezpečnosť na úrovni databázy a pravidelné bezpečnostné audity.

Výkonnostné úvahy

Výzvy zdieľanej databázy

V zdieľanej databáze všetci tenanti súťažia o rovnaké zdroje. Tenant spúšťajúci ťažký report môže spomaliť dotazy pre všetkých ostatných. Opatrenia zahŕňajú:

• Connection pooling. Používajte PgBouncer alebo podobný nástroj, aby jeden tenant nevyčerpal databázové pripojenia.
• Časové limity dotazov. Nastavte maximálne časy vykonávania, aby nekontrolovateľný dotaz nemohol zamknúť zdroje neobmedzene.
• Rate limiting. Vynúťte per-tenant limity na API požiadavky a databázové operácie.
• Čítacie repliky. Smerujte ťažké čítacie operácie (reporty, exporty) na repliku, aby neovplyvnili primárnu databázu.

Výhody oddelenej databázy

S per-tenant databázami je výkonnostná izolácia zabudovaná. Vysoké zaťaženie jedného tenanta ovplyvňuje len jeho vlastnú databázu. Môžete tiež poskytnúť väčšie alebo menšie databázy na základe plánu a využitia každého tenanta.

Kompromis je režijná záťaž správy. Monitorovanie 500 databáz je ťažšie ako monitorovanie jednej. Automatizované nástroje sa stávajú nevyhnutnými.

Nákladové implikácie vo veľkom meradle

Pozrime sa na orientačné čísla. Predpokladajme, že máte 100 tenantov.

Zdieľaná databáza (multi-tenant):

• 1 aplikačný cluster: ~200 EUR/mesiac
• 1 spravovaná inštancia PostgreSQL: ~100 EUR/mesiac
• Celkom: ~300 EUR/mesiac (3 EUR na tenanta)

Oddelené databázy (multi-tenant):

• 1 aplikačný cluster: ~200 EUR/mesiac
• 100 malých databázových inštancií: ~2 000 EUR/mesiac
• Celkom: ~2 200 EUR/mesiac (22 EUR na tenanta)

Single-tenant:

• 100 aplikačných inštancií: ~5 000 EUR/mesiac
• 100 databázových inštancií: ~2 000 EUR/mesiac
• Celkom: ~7 000 EUR/mesiac (70 EUR na tenanta)

Tieto čísla sú zjednodušené, ale vzor platí. Zdieľaná infraštruktúra je dramaticky lacnejšia. Pri 1 000 tenantoch sa rozdiel ešte zväčší.

Preto musia ceny zodpovedať architektúre. Ak účtujete 20 EUR mesačne a prevádzkujete single-tenant infraštruktúru za 70 EUR na tenanta, na každom zákazníkovi strácate peniaze.

Kedy zvoliť multi-tenant

Multi-tenant architektúra je správna voľba, keď:

• Budujete B2B SaaS pre SMB. Vysoký objem, nižšie cenové body a štandardné sady funkcií.
• Nákladová efektívnosť je dôležitá. Potrebujete udržiavať infraštruktúrne náklady nízke v pomere k príjmom.
• Chcete rýchle, uniformné aktualizácie. Nasaďte raz, všetci tenanti dostanú vylepšenie.
• Vaši zákazníci nevyžadujú dedikovanú infraštruktúru. Väčšine malým a stredným firmám nezáleží na tom, kde ich dáta žijú, pokiaľ sú v bezpečí.
• Ste v ranom štádiu. Začnite multi-tenant. Je lacnejší a jednoduchší. Dedikovanú úroveň pre enterprise zákazníkov môžete vždy pridať neskôr.

Kedy zvoliť single-tenant

Single-tenant architektúra má zmysel, keď:

• Predávate enterprise zákazníkom. Veľké organizácie často vyžadujú dedikovanú infraštruktúru ako súčasť obstarávacieho procesu.
• Súlad to vyžaduje. Odvetvia ako zdravotníctvo (HIPAA), financie (SOX, PCI-DSS) a štátna správa majú prísne požiadavky na izoláciu dát.
• Zákazníci potrebujú prispôsobenie. Ak každý zákazník vyžaduje rôzne konfigurácie, integrácie alebo dokonca funkcie, single-tenant vám dáva flexibilitu.
• Váš cenový bod to podporuje. Ak účtujete 5 000 EUR alebo viac mesačne na zákazníka, infraštruktúrne náklady sú ľahko opodstatnené.
• Rezidencia dát je tvrdá požiadavka. Keď dáta musia sídliť v konkrétnej krajine, oddelená infraštruktúra per tenant je najpriamočiarejší prístup.

Hybridné prístupy

Nemusíte si vybrať len jeden. Mnohé úspešné SaaS spoločnosti používajú hybridný model:

• Multi-tenant pre štandardné úrovne. Free, starter a pro zákazníci zdieľajú infraštruktúru. Toto udržiava náklady nízke a umožňuje škálovanie.
• Single-tenant pre enterprise. Prémioví zákazníci dostávajú dedikované inštancie s vlastnými SLA, certifikáciami súladu a dedikovanou podporou.

Aplikačný kód je rovnaký. Model nasadenia sa líši. Toto vyžaduje dobrú automatizáciu infraštruktúry, ale je to overený vzor.

Ako implementovať hybridný model

1. Vybudujte aplikáciu najprv ako multi-tenant. Všetka logika izolácie tenantov zostáva rovnaká bez ohľadu na model nasadenia.
2. Používajte infrastructure-as-code (Terraform, Pulumi alebo CDK) na automatizáciu vytvárania prostredí.
3. Vytvorte provisioning pipeline, ktorý dokáže roztočiť nové dedikované prostredie za minúty, nie dni.
4. Udržiavajte jednu kódovú základňu. Rovnaký Docker image beží v zdieľaných aj dedikovaných prostrediach. Konfigurácia (nie kód) určuje správanie.

Databázové stratégie podrobne

Databáza je miesto, kde majú rozhodnutia o tenancy najväčší dopad. Tu sú tri overené stratégie.

Stratégia 1: Zdieľané tabuľky s tenant_id

Každá tabuľka má stĺpec tenant_id. Všetky dotazy podľa neho 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;

Najlepšie pre: väčšinu SaaS produktov. Jednoduché, nákladovo efektívne, dobre pochopené.

Stratégia 2: Schéma per tenant

Každý tenant dostane vlastnú PostgreSQL schému v rámci zdieľanej databázy. Tabuľky majú rovnakú štruktúru, ale dáta sú fyzicky oddelené.

-- 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;

Najlepšie pre: produkty, ktoré potrebujú silnejšiu izoláciu ako na úrovni riadkov, ale nechcú náklady oddelených databáz. Funguje dobre do niekoľkých stoviek tenantov.

Stratégia 3: Oddelené databázy

Každý tenant dostane dedikovanú inštanciu PostgreSQL (alebo dedikovanú databázu na zdieľanom serveri).

// 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`);
  }
}

Najlepšie pre: enterprise SaaS s vysoko hodnotnými zákazníkmi, prísnymi požiadavkami na súlad alebo povinnosťami rezidencii dát.

Rozhodovanie

Tu je jednoduchý rozhodovací rámec:

1. Aká je veľkosť vášho cieľového zákazníka? SMB ukazuje na multi-tenant. Enterprise ukazuje na single-tenant alebo hybridný prístup.
2. Aký je váš cenový bod? Pod 100 EUR/mesiac potrebujete multi-tenant, aby ste boli ziskoví. Nad 1 000 EUR/mesiac sa single-tenant stáva životaschopným.
3. Aké sú požiadavky na súlad? Regulované odvetvia často vyžadujú silnejšiu izoláciu.
4. Koľko tenantov očakávate? Stovky alebo tisíce tenantov potrebujú zdieľanú infraštruktúru. Desať až päťdesiat veľkých tenantov môže fungovať s dedikovanými inštanciami.
5. Aká je prevádzková kapacita vášho tímu? Single-tenant vyžaduje viac DevOps investícií. Multi-tenant je prevádzkovo jednoduchší.

Ak si nie ste istí, začnite s multi-tenant so zdieľanou databázou a row-level security. Je to najlacnejšia možnosť, pri správnej implementácii je bezpečná a udržiava vašu architektúru jednoduchú. Dedikovanú úroveň pre enterprise zákazníkov môžete vždy pridať neskôr.

Záver

Neexistuje univerzálne správny model tenancy. Správna voľba závisí od vašich zákazníkov, vašich cien, vašich požiadaviek na súlad a vašich prevádzkových schopností.

Väčšina SaaS produktov by mala začať multi-tenant. Je lacnejší, jednoduchší a dobre škáluje. Ako sa posúvate na vyšší trh a začnete predávať väčším organizáciám, pridajte single-tenant možnosti pre zákazníkov, ktorí ich potrebujú a sú ochotní za ne platiť.

Architektúra by mala slúžiť biznisu, nie naopak. Budujte pre zákazníkov, ktorých máte dnes, a navrhujte s dostatočnou flexibilitou na obsluhu zákazníkov, ktorých chcete zajtra.

---

Potrebujete pomoc s výberom správnej architektúry pre váš SaaS produkt? Budovali sme multi-tenant a single-tenant systémy naprieč odvetviami. Poďme zistiť najlepší prístup pre váš projekt.