Multi-tenant naspram single-tenant | Odabir prave SaaS arhitekture

Svaki SaaS proizvod treba odgovoriti na temeljno pitanje: kako sluzite vise korisnika iz istog softvera? Odgovor je vas model najma. Utjece na trosak, sigurnost, performanse i brzinu isporuke. Ispravna odluka na pocetku stedi vas bolnih migracija kasnije.

Definicije

Multi-tenant

Jedna instanca aplikacije sluzi sve korisnike. Svi dijele iste servere, istu bazu koda i cesto istu bazu podataka. Podaci svakog korisnika su logicki izolirani, ali infrastruktura je zajednicka.

Zamislite to kao stambenu zgradu. Svaki stanar zivi u istoj zgradi, dijeli dizalo i hodnike, ali ima vlastiti zakljucani stan s vlastitim namjestajem.

Single-tenant

Svaki korisnik dobiva vlastitu dediciranu instancu aplikacije. Odvojeni serveri, odvojene baze podataka, ponekad odvojene baze koda. Nista se ne dijeli izmedu korisnika.

Zamislite to kao samostojece kuce. Svaki stanar ima vlastitu zgradu, vlastite instalacije, vlastito dvoriste. Potpuna izolacija, ali skuplje za odrzavanje.

Kako multi-tenancy funkcionira

Postoje tri uobicajena pristupa multi-tenant arhitekturi, svaki s razlicitim kompromisima.

Model 1: Zajednicka aplikacija, zajednicka baza podataka

Svi korisnici dijele jednu instancu aplikacije i jednu bazu podataka. Podaci korisnika su odvojeni koristeci identifikator korisnika (obicno tenant_id stupac) na svakoj tablici.

Arhitektura:

• Jedan aplikacijski server (ili klaster) obrdduje sve zahtjeve.
• Jedna baza podataka pohranjuje sve korisnicke podatke.
• Svaki upit ukljucuje WHERE tenant_id = ? klauzulu za opseg podataka na ispravnog korisnika.

Prednosti:

• Najnizi trosak infrastrukture. Jedna baza podataka, jedno postavljanje aplikacije.
• Najjednostavnije za postavljanje i azuriranje. Pogurajte jednom, svi dobiju promjenu.
• Lako agregirati podatke kroz korisnike za analitiku i izvjestavanje.

Nedostaci:

• Najvisi rizik curenja podataka ako upit zaboravi filter korisnika.
• Jedan buecan korisnik moze degradirati performanse za sve.
• Migracije baze podataka utjecu na sve korisnike istovremeno.
• Najteze za uskladenost sa zahtjevima rezidentnosti podataka.

Ovo je najcesi pristup za B2B SaaS proizvode s velikim brojem malih do srednjih korisnika.

Model 2: Zajednicka aplikacija, odvojene baze podataka

Svi korisnici dijele istu instancu aplikacije, ali svaki korisnik dobiva vlastitu bazu podataka. Aplikacija usmjerava upite u ispravnu bazu podataka na temelju autentificiranog korisnika.

Arhitektura:

• Jedan aplikacijski server (ili klaster) obraduje sve zahtjeve.
• Odvojena baza podataka za svakog korisnika.
• Sloj usmjeravanja mapira identitet korisnika na ispravnu vezu baze podataka.

Prednosti:

• Jaca izolacija podataka. Nema rizika od upita koji prelaze korisnike.
• Lakse zadovoljiti zahtjeve rezidentnosti podataka. Mozete smjestiti svaku bazu podataka u regiju koju korisnik zahtijeva.
• Sigurnosna kopija i obnova po korisniku je jednostavna.
• Tesko koristenje jednog korisnika nece zakljucati tablice za druge korisnike.

Nedostaci:

• Vise infrastrukture za upravljanje. Stotine korisnika znaci stotine baza podataka.
• Migracije shema moraju se primijeniti na svaku bazu podataka pojedinacno.
• Izvjestavanje kroz korisnike zahtijeva upite na vise baza podataka.
• Visi trosak od potpuno zajednickog modela.

Ovo je snazna sredina za proizvode kojima treba bolja izolacija bez troska pune single-tenancy.

Model 3: Odvojena aplikacija, odvojena baza podataka

Svaki korisnik dobiva vlastitu instancu aplikacije i vlastitu bazu podataka. Potpuno izolirano. Ovo je u osnovi single-tenancy, ali upravljana od strane SaaS pruzatelja umjesto korisnika.

Arhitektura:

• Dedicirano postavljanje aplikacije po korisniku.
• Dedicirana baza podataka po korisniku.
• Sloj usmjeravanja (cesto load balancer ili API gateway) usmjerava promet na ispravnu instancu.

Prednosti:

• Potpuna izolacija. Nema zajednickih resursa izmedu korisnika.
• Maksimalna fleksibilnost za prilagodbu po korisniku.
• Performanse jednog korisnika nikada ne utjecu na drugog.
• Najjednostavnija prica uskladenosti.

Nedostaci:

• Daleko najvisi trosak infrastrukture.
• Slozenost postavljanja raste linearno s brojem korisnika.
• Azuriranja se moraju rasipriti na svaku instancu pojedinacno (ili vrlo pazljivo automatizirati).
• Ne skalira se ekonomski za veliki broj malih korisnika.

Ovaj model ima smisla za enterprise SaaS gdje korisnici zahtijevaju dediciranu infrastrukturu i spremni su platiti premiju za to.

Prednosti i nedostaci na prvi pogled

Faktor	Multi-tenant (zajednicka BP)	Multi-tenant (odvojene BP)	Single-tenant
Trosak infrastrukture	Najnizi	Srednji	Najvisi
Izolacija podataka	Logicka (na razini redaka)	Fizicka (na razini baze)	Potpuna
Slozenost postavljanja	Niska	Srednja	Visoka
Brzina azuriranja	Trenutacno za sve	Trenutacna app, migracije po BP	Isporuka po instanci
Prilagodba	Ogranicena	Ogranicena	Potpuna
Uskladenost	Teze	Umjereno	Najlaksa
Skalabilnost (broj korisnika)	Izvrsna	Dobra	Losa
Rizik busnog susjeda	Visok	Srednji	Nikakav

Izolacija podataka i sigurnost

Izolacija podataka je najvaznije razmatranje u bilo kojem modelu najma. Sigurnosna povreda u kojoj jedan korisnik moze pristupiti podacima drugog korisnika je katastrofalna za SaaS poslovanje. Moze unistiti povjerenje, prekrsiti propise i zavrsti tvrtku.

Sigurnost na razini redaka

U modelu zajednicke baze podataka, PostgreSQL-ov Row-Level Security (RLS) je jedna od najjacih obrana protiv curenja podataka. RLS namece izolaciju korisnika na razini baze podataka, ne na razini aplikacije. Cak i ako vas aplikacijski kod ima gresku koja zaboravi filtrirati po korisniku, sama baza podataka sprecava pristup podacima drugog korisnika.

Evo kako ga postaviti:

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

Prije izvrsavanja bilo kojeg upita, postavite kontekst korisnika:

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

Izolacija na razini aplikacije

Osim sigurnosti na razini baze podataka, vasa aplikacija treba nametnuti granice korisnika:

// 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 u dubinu je princip ovdje. Nikada se ne oslanjajte na jedan sloj izolacije. Kombinirajte filtriranje na razini aplikacije, sigurnost na razini baze podataka i redovite sigurnosne revizije.

Razmatranja performansi

Izazovi zajednicke baze podataka

U zajednickoj bazi podataka, svi korisnici se natjecu za iste resurse. Korisnik koji pokrece tesk izvjestaj moze usporiti upite za sve ostale. Ublazavanja ukljucuju:

• Pool veza. Koristite PgBouncer ili slican alat kako biste sprijecili jednog korisnika da iscrpi veze baze podataka.
• Vremenski limiti upita. Postavite maksimalna vremena izvrsavanja kako odbjegel upit ne bi mogao zakljucati resurse neograniceno.
• Ogranicenje brzine. Nametnite ogranicenja po korisniku na API zahtjeve i operacije baze podataka.
• Replike za citanje. Usmjerite teske operacije citanja (izvjestaji, izvozi) na repliku kako ne bi utjecale na primarnu bazu podataka.

Prednosti odvojenih baza podataka

S bazama podataka po korisniku, izolacija performansi je ugradujeni. Tesko opterecenje jednog korisnika utjece samo na njihovu vlastitu bazu podataka. Takoder mozete dodijeliti vece ili manje baze podataka na temelju plana i koristenja svakog korisnika.

Kompromis je overhead upravljanja. Nadzor 500 baza podataka je tezi od nadzora jedne. Automatizirani alati postaju neophodni.

Implikacije troskova na skali

Pogledajmo neke okvirne brojeve. Pretpostavimo da imate 100 korisnika.

Zajednicka baza podataka (multi-tenant):

• 1 aplikacijski klaster: ~200 EUR/mjesecno
• 1 upravljana PostgreSQL instanca: ~100 EUR/mjesecno
• Ukupno: ~300 EUR/mjesecno (3 EUR po korisniku)

Odvojene baze podataka (multi-tenant):

• 1 aplikacijski klaster: ~200 EUR/mjesecno
• 100 malih instanci baza podataka: ~2.000 EUR/mjesecno
• Ukupno: ~2.200 EUR/mjesecno (22 EUR po korisniku)

Single-tenant:

• 100 instanci aplikacije: ~5.000 EUR/mjesecno
• 100 instanci baza podataka: ~2.000 EUR/mjesecno
• Ukupno: ~7.000 EUR/mjesecno (70 EUR po korisniku)

Ovi brojevi su pojednostavljeni, ali obrazac stoji. Zajednicka infrastruktura je dramaticno jeftinija. S 1.000 korisnika, jaz postaje jos siri.

Zato se cijene moraju uskladiti s arhitekturom. Ako naplacujete 20 EUR mjesecno, a pokreece single-tenant infrastrukturu po 70 EUR po korisniku, gubite novac na svakom korisniku.

Kada odabrati multi-tenant

Multi-tenant arhitektura je pravi izbor kada:

• Gradite B2B SaaS za SMB-ove. Visoki volumen, nize cjenovne tocke i standardni skupovi funkcionalnosti.
• Troskovnia ucinkovitost je vazna. Trebate drzati troskove infrastrukture niskima u odnosu na prihod.
• Zelite brza, ujednacena azuriranja. Postavite jednom, svi korisnici dobiju poboljsanje.
• Vasi korisnici ne zahtijevaju dediciranu infrastrukturu. Vecini malih i srednjih tvrtki nije stalo gdje im zive podaci, sve dok su sigurni.
• U ranoj ste fazi. Pocnite multi-tenant. Jeftiniji je i jednostavniji. Uvijek mozete ponuditi single-tenant kasnije za enterprise korisnike.

Kada odabrati single-tenant

Single-tenant arhitektura ima smisla kada:

• Prodajete enterpriseima. Velike organizacije cesto zahtijevaju dediciranu infrastrukturu kao dio procesa nabave.
• Uskladenost to zahtijeva. Industrije poput zdravstva (HIPAA), financija (SOX, PCI-DSS) i vlade imaju stroge zahtjeve za izolaciju podataka.
• Korisnici trebaju prilagodbu. Ako svaki korisnik zahtijeva razlicite konfiguracije, integracije ili cak funkcionalnosti, single-tenant vam daje fleksibilnost.
• Vasa cjenovna tocka to podrzava. Ako naplacujete 5.000 EUR ili vise mjesecno po korisniku, trosak infrastrukture je lako opravdan.
• Rezidentnost podataka je strogi zahtjev. Kada podaci moraju boraviti u odredenoj zemlji, odvojena infrastruktura po korisniku je najjednostavniji pristup.

Hibridni pristupi

Ne morate odabrati samo jedno. Mnoge uspjesne SaaS tvrtke koriste hibridni model:

• Multi-tenant za standardne razine. Besplatni, pocetni i pro korisnici dijele infrastrukturu. Ovo drzi troskove niskima i omogucuje skaliranje.
• Single-tenant za enterprise. Premium korisnici dobivaju dedicirane instance s prilagodenim SLA-ovima, certifikatima uskladenosti i dediciranom podrskom.

Aplikacijski kod je isti. Model postavljanja se razlikuje. Ovo zahtijeva dobru automatizaciju infrastrukture, ali to je dokazani obrazac.

Kako implementirati hibridni model

1. Najprije izgradite aplikaciju kao multi-tenant. Sva logika izolacije korisnika ostaje ista bez obzira na model postavljanja.
2. Koristite infrastrukturu kao kod (Terraform, Pulumi ili CDK) za automatizaciju kreiranja okruzenja.
3. Stvorite pipeline za aprovizioniranje koji moze pokrenuti novo dedicirano okruzenje u minutama, ne danima.
4. Odrzavajte jednu bazu koda. Ista Docker slika radi i u zajednickim i u dediciranim okruzenjima. Konfiguracija (ne kod) odreduje ponasanje.

Strategije baze podataka u detalju

Baza podataka je mjesto gdje odluke o najmu imaju najveci utjecaj. Evo tri dokazane strategije.

Strategija 1: Zajednicke tablice s tenant_id

Svaka tablica ima tenant_id stupac. Svi upiti filtriraju po njemu.

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;

Najbolje za: vecinu SaaS proizvoda. Jednostavno, troiskovno ucinkovito, dobro razumjeno.

Strategija 2: Shema po korisniku

Svaki korisnik dobiva vlastitu PostgreSQL shemu unutar zajednicke baze podataka. Tablice imaju istu strukturu, ali podaci su fizicki odvojeni.

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

Najbolje za: proizvode kojima treba jaca izolacija od razine redaka, ali ne zele trosak odvojenih baza podataka. Dobro funkcionira do nekoliko stotina korisnika.

Strategija 3: Odvojene baze podataka

Svaki korisnik dobiva dediciranu PostgreSQL instancu (ili dediciranu bazu podataka na zajednickom 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`);
  }
}

Najbolje za: enterprise SaaS s korisnicima visoke vrijednosti, strogim zahtjevima uskladenosti ili obvezama rezidentnosti podataka.

Donosenje odluke

Evo jednostavnog okvira za odlucivanje:

1. Koja je vasa ciljna velicina korisnika? SMB pokazuje prema multi-tenant. Enterprise pokazuje prema single-tenant ili hibridnom.
2. Koja je vasa cjenovna tocka? Ispod 100 EUR/mjesecno, trebate multi-tenant da biste bili profitabilni. Iznad 1.000 EUR/mjesecno, single-tenant postaje izvediv.
3. Koji su zahtjevi uskladenosti? Regulirane industrije cesto zahtijevaju jacu izolaciju.
4. Koliko korisnika ocekujete? Stotine ili tisuce korisnika trebaju zajednicku infrastrukturu. Deset do pedeset velikih korisnika mogu raditi s dediciranim instancama.
5. Kakav je operativni kapacitet vaseg tima? Single-tenant zahtijeva vise DevOps ulaganja. Multi-tenant je operativno jednostavniji.

Ako niste sigurni, pocnite s multi-tenantom koristeci zajednicku bazu podataka i sigurnost na razini redaka. To je opcija s najnizim troskom, sigurna je kada je ispravno implementirana i drzi vasu arhitekturu jednostavnom. Uvijek mozete dodati dediciranu razinu za enterprise korisnike kasnije.

Zakljucak

Ne postoji univerzalno ispravan model najma. Pravi izbor ovisi o vasim korisnicima, vasim cijenama, vasim zahtjevima uskladenosti i vasim operativnim sposobnostima.

Vecina SaaS proizvoda bi trebala poceti multi-tenant. Jeftiniji je, jednostavniji i dobro se skalira. Kako se pomicete prema trzisnom segmentu i pocnete prodavati vecim organizacijama, dodajte single-tenant opcije za korisnike koji ih trebaju i koji ce platiti u skladu s tim.

Arhitektura treba sluziti poslovanju, ne obrnuto. Gradite za korisnike koje imate danas i dizajnirajte s dovoljno fleksibilnosti da sluzite korisnike koje zelite sutra.

---

Trebate pomoc pri odabiru prave arhitekture za vas SaaS proizvod? Izgradili smo multi-tenant i single-tenant sustave kroz industrije. Odredimo najbolji pristup za vas projekt.