Multi-tenant vs single-tenant | Välja rätt SaaS-arkitektur

Varje SaaS-produkt behöver besvara en grundläggande fråga: hur betjänar du flera kunder från samma mjukvara? Svaret är din hyresgästmodell. Den påverkar kostnad, säkerhet, prestanda och hur snabbt du kan leverera. Att välja rätt tidigt sparar dig från smärtsamma migreringar längre fram.

Definitioner

Multi-tenant

En instans av applikationen betjänar alla kunder. Alla delar samma servrar, samma kodbas och ofta samma databas. Varje kunds data är logiskt isolerad, men infrastrukturen är delad.

Tänk på det som ett flerfamiljshus. Varje hyresgäst bor i samma byggnad, delar hiss och trapphus, men har sin egen låsta lägenhet med sina egna möbler.

Single-tenant

Varje kund får sin egen dedikerade instans av applikationen. Separata servrar, separata databaser, ibland separata kodbaser. Ingenting delas mellan kunder.

Tänk på det som fristående hus. Varje hyresgäst har sin egen byggnad, sin egen rördragning, sin egen trädgård. Fullständig isolering, men dyrare att underhålla.

Hur multi-tenancy fungerar

Det finns tre vanliga tillvägagångssätt för multi-tenant-arkitektur, vart och ett med olika avvägningar.

Modell 1: Delad applikation, delad databas

Alla hyresgäster delar en enda applikationsinstans och en enda databas. Hyresgästdata separeras med en hyresgästidentifierare (vanligtvis en tenant_id-kolumn) i varje tabell.

Arkitektur:

• En applikationsserver (eller ett kluster) hanterar alla förfrågningar.
• En databas lagrar all hyresgästdata.
• Varje fråga inkluderar en WHERE tenant_id = ?-klausul för att avgränsa data till rätt hyresgäst.

Fördelar:

• Lägsta infrastrukturkostnaden. En databas, en appdriftsättning.
• Enklast att driftsätta och uppdatera. Pusha en gång, alla får ändringen.
• Enkelt att aggregera data över hyresgäster för analys och rapportering.

Nackdelar:

• Högsta risken för dataläckage om en fråga glömmer hyresgästfiltret.
• En resurskrävande hyresgäst kan försämra prestandan för alla.
• Databasmigrationer påverkar alla hyresgäster samtidigt.
• Svårast att uppfylla krav på datalagring i specifika regioner.

Detta är det vanligaste tillvägagångssättet för B2B SaaS-produkter med ett stort antal små till medelstora kunder.

Modell 2: Delad applikation, separata databaser

Alla hyresgäster delar samma applikationsinstans, men varje hyresgäst får sin egen databas. Applikationen dirigerar frågor till rätt databas baserat på den autentiserade hyresgästen.

Arkitektur:

• En applikationsserver (eller ett kluster) hanterar alla förfrågningar.
• En separat databas för varje hyresgäst.
• Ett routinglager mappar hyresgästens identitet till rätt databasanslutning.

Fördelar:

• Starkare dataisolering. Ingen risk för frågor som korsar hyresgästgränser.
• Enklare att uppfylla krav på datalagring. Du kan placera varje databas i hyresgästens önskade region.
• Säkerhetskopiering och återställning per hyresgäst är rakt på sak.
• En hyresgästs tunga användning låser inte tabeller för andra hyresgäster.

Nackdelar:

• Mer infrastruktur att hantera. Hundratals hyresgäster innebär hundratals databaser.
• Schemamigrationer måste tillämpas på varje databas individuellt.
• Rapportering över hyresgäster kräver frågor mot flera databaser.
• Högre kostnad än en helt delad modell.

Detta är en stark mellanväg för produkter som behöver bättre isolering utan kostnaden för fullständig single-tenancy.

Modell 3: Separat applikation, separat databas

Varje hyresgäst får sin egen applikationsinstans och sin egen databas. Fullständigt isolerad. Detta är i princip single-tenancy, men hanterad av SaaS-leverantören istället för kunden.

Arkitektur:

• En dedikerad appdriftsättning per hyresgäst.
• En dedikerad databas per hyresgäst.
• Ett routinglager (ofta en lastbalanserare eller API-gateway) dirigerar trafik till rätt instans.

Fördelar:

• Fullständig isolering. Inga delade resurser mellan hyresgäster.
• Maximal flexibilitet för anpassning per hyresgäst.
• En hyresgästs prestanda påverkar aldrig en annan.
• Enklaste scenariot för efterlevnad.

Nackdelar:

• Högsta infrastrukturkostnaden med stor marginal.
• Driftsättningens komplexitet växer linjärt med antalet hyresgäster.
• Uppdateringar måste rullas ut till varje instans individuellt (eller automatiseras mycket noggrant).
• Skalar inte ekonomiskt för stora mängder små hyresgäster.

Denna modell passar för enterprise-SaaS där kunder kräver dedikerad infrastruktur och är villiga att betala extra för det.

Fördelar och nackdelar i översikt

Faktor	Multi-tenant (delad DB)	Multi-tenant (separat DB)	Single-tenant
Infrastrukturkostnad	Lägst	Medel	Högst
Dataisolering	Logisk (radnivå)	Fysisk (databasnivå)	Fullständig
Driftsättningskomplexitet	Låg	Medel	Hög
Uppdateringshastighet	Omedelbart för alla	Omedelbar app, migrering per databas	Utrullning per instans
Anpassning	Begränsad	Begränsad	Fullständig
Efterlevnad	Svårare	Måttlig	Enklast
Skalbarhet (antal hyresgäster)	Utmärkt	Bra	Dålig
Risk för bullrig granne	Hög	Medel	Ingen

Dataisolering och säkerhet

Dataisolering är den viktigaste aspekten i alla hyresgästmodeller. Ett säkerhetsintrång där en hyresgäst kan komma åt en annan hyresgästs data är katastrofalt för en SaaS-verksamhet. Det kan förstöra förtroendet, bryta mot regelverk och sätta stopp för företaget.

Säkerhet på radnivå

I en delad databasmodell är PostgreSQL:s Row-Level Security (RLS) ett av de starkaste skydden mot dataläckage. RLS upprätthåller hyresgästisolering på databasnivå, inte applikationsnivå. Även om din applikationskod har en bugg som glömmer att filtrera per hyresgäst förhindrar databasen själv åtkomst över hyresgästgränser.

Så här konfigurerar du det:

-- Aktivera RLS på en tabell
ALTER TABLE projects ENABLE ROW LEVEL SECURITY;

-- Skapa en policy som begränsar åtkomst till aktuell hyresgäst
CREATE POLICY tenant_isolation ON projects
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);

-- Tvinga RLS även för tabellägare
ALTER TABLE projects FORCE ROW LEVEL SECURITY;

Innan du kör en fråga, sätt hyresgästkontexten:

-- Sätt i början av varje förfrågan/transaktion
SET LOCAL app.current_tenant_id = 'a1b2c3d4-e5f6-7890-abcd-ef1234567890';

-- Nu returnerar denna fråga automatiskt bara den aktuella hyresgästens data
SELECT * FROM projects;
-- Ingen WHERE-klausul behövs. RLS hanterar det.

Isolering på applikationsnivå

Utöver säkerhet på databasnivå bör din applikation upprätthålla hyresgästgränser:

// Middleware som sätter hyresgästkontext på varje förfrågan
async function tenantMiddleware(req: Request, res: Response, next: NextFunction) {
  const tenantId = extractTenantId(req); // Från JWT, subdomän eller header

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

  // Sätt hyresgästkontext för databasanslutningen
  await db.raw(`SET LOCAL app.current_tenant_id = '${tenantId}'`);

  req.tenantId = tenantId;
  next();
}

Försvar på djupet är principen här. Förlita dig aldrig på ett enda lager av isolering. Kombinera filtrering på applikationsnivå, säkerhet på databasnivå och regelbundna säkerhetsgranskningar.

Prestandaöverväganden

Utmaningar med delad databas

I en delad databas konkurrerar alla hyresgäster om samma resurser. En hyresgäst som kör en tung rapport kan sakta ner frågor för alla andra. Motåtgärder inkluderar:

• Anslutningspoolning. Använd PgBouncer eller ett liknande verktyg för att förhindra att en hyresgäst uttömmer databasanslutningar.
• Tidsbegränsningar för frågor. Sätt maximala körtider så att en skenande fråga inte kan låsa resurser på obestämd tid.
• Hastighetsbegränsning. Tillämpa gränser per hyresgäst på API-förfrågningar och databasoperationer.
• Läsreplikor. Dirigera tunga läsoperationer (rapporter, exporter) till en replika så att de inte påverkar den primära databasen.

Fördelar med separata databaser

Med databaser per hyresgäst är prestandaisolering inbyggd. En hyresgästs tunga arbetsbelastning påverkar bara deras egen databas. Du kan också tilldela större eller mindre databaser baserat på varje hyresgästs plan och användning.

Avvägningen är förvaltningskostnader. Att övervaka 500 databaser är svårare än att övervaka en. Automatiserade verktyg blir nödvändiga.

Kostnadskonsekvenser i stor skala

Låt oss titta på ungefärliga siffror. Anta att du har 100 hyresgäster.

Delad databas (multi-tenant):

• 1 applikationskluster: ~200 €/månad
• 1 hanterad PostgreSQL-instans: ~100 €/månad
• Totalt: ~300 €/månad (3 € per hyresgäst)

Separata databaser (multi-tenant):

• 1 applikationskluster: ~200 €/månad
• 100 små databasinstanser: ~2 000 €/månad
• Totalt: ~2 200 €/månad (22 € per hyresgäst)

Single-tenant:

• 100 applikationsinstanser: ~5 000 €/månad
• 100 databasinstanser: ~2 000 €/månad
• Totalt: ~7 000 €/månad (70 € per hyresgäst)

Dessa siffror är förenklade, men mönstret håller. Delad infrastruktur är dramatiskt billigare. Med 1 000 hyresgäster blir skillnaden ännu större.

Det är därför prissättningen måste stämma överens med arkitekturen. Om du tar 20 € per månad och kör single-tenant-infrastruktur till 70 € per hyresgäst förlorar du pengar på varje kund.

När du bör välja multi-tenant

Multi-tenant-arkitektur är rätt val när:

• Du bygger B2B SaaS för små och medelstora företag. Hög volym, lägre prispunkter och standardiserade funktioner.
• Kostnadseffektivitet är viktigt. Du behöver hålla infrastrukturkostnaderna låga i förhållande till intäkterna.
• Du vill ha snabba, enhetliga uppdateringar. Driftsätt en gång, alla hyresgäster får förbättringen.
• Dina kunder kräver inte dedikerad infrastruktur. De flesta små och medelstora företag bryr sig inte om var deras data lagras, så länge den är säker.
• Du befinner dig i ett tidigt skede. Börja med multi-tenant. Det är billigare och enklare. Du kan alltid erbjuda single-tenant senare för enterprise-kunder.

När du bör välja single-tenant

Single-tenant-arkitektur är lämplig när:

• Du säljer till stora företag. Stora organisationer kräver ofta dedikerad infrastruktur som en del av sin upphandlingsprocess.
• Regelefterlevnad kräver det. Branscher som hälso- och sjukvård (HIPAA), finans (SOX, PCI-DSS) och offentlig sektor har strikta krav på dataisolering.
• Kunder behöver anpassning. Om varje kund kräver olika konfigurationer, integrationer eller till och med funktioner ger single-tenant dig flexibiliteten.
• Din prispunkt motiverar det. Om du tar 5 000 € eller mer per månad per kund är infrastrukturkostnaden lätt motiverad.
• Datalagring i specifikt land är ett absolut krav. När data måste lagras i ett specifikt land är separat infrastruktur per hyresgäst det mest raka tillvägagångssättet.

Hybridmodeller

Du behöver inte välja bara en modell. Många framgångsrika SaaS-företag använder en hybridmodell:

• Multi-tenant för standardnivåer. Gratis-, start- och pro-kunder delar infrastruktur. Det håller kostnaderna nere och låter dig skala.
• Single-tenant för enterprise. Premiumkunder får dedikerade instanser med anpassade SLA:er, efterlevnadscertifieringar och dedikerad support.

Applikationskoden är densamma. Driftsättningsmodellen skiljer sig åt. Detta kräver bra infrastrukturautomatisering, men det är ett beprövat mönster.

Hur du implementerar en hybridmodell

1. Bygg appen som multi-tenant först. All logik för hyresgästisolering förblir densamma oavsett driftsättningsmodell.
2. Använd infrastruktur som kod (Terraform, Pulumi eller CDK) för att automatisera skapandet av miljöer.
3. Skapa en provisioneringspipeline som kan starta en ny dedikerad miljö på minuter, inte dagar.
4. Behåll en enda kodbas. Samma Docker-avbild körs i både delade och dedikerade miljöer. Konfiguration (inte kod) styr beteendet.

Databasstrategier i detalj

Databasen är platsen där beslut om hyresgästmodell har störst påverkan. Här är tre beprövade strategier.

Strategi 1: Delade tabeller med tenant_id

Varje tabell har en tenant_id-kolumn. Alla frågor filtrerar på den.

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

-- Fråga alltid med hyresgästkontext
SELECT * FROM projects WHERE tenant_id = $1;

Bäst för: De flesta SaaS-produkter. Enkelt, kostnadseffektivt och välförstått.

Strategi 2: Schema per hyresgäst

Varje hyresgäst får sitt eget PostgreSQL-schema inom en delad databas. Tabellerna har samma struktur, men data är fysiskt separerad.

-- Skapa ett schema för en ny hyresgäst
CREATE SCHEMA tenant_abc123;

-- Skapa tabeller i hyresgästens schema
CREATE TABLE tenant_abc123.projects (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Sätt sökvägen per förfrågan
SET search_path TO tenant_abc123, public;

-- Nu är frågor automatiskt avgränsade
SELECT * FROM projects;

Bäst för: Produkter som behöver starkare isolering än radnivå men inte vill ha kostnaden för separata databaser. Fungerar bra upp till några hundra hyresgäster.

Strategi 3: Separata databaser

Varje hyresgäst får en dedikerad PostgreSQL-instans (eller en dedikerad databas på en delad server).

// Routing av databasanslutningar
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> {
    // Slå upp hyresgästens databasanslutningsuppgifter
    // från en central konfigurationslagring
    return await configStore.get(`tenants/${tenantId}/database`);
  }
}

Bäst för: Enterprise-SaaS med högvärdiga kunder, strikta efterlevnadskrav eller krav på datalagring i specifika regioner.

Att fatta beslutet

Här är ett enkelt beslutsramverk:

1. Vilken är din målkundstorlek? Små och medelstora företag pekar mot multi-tenant. Enterprise pekar mot single-tenant eller hybrid.
2. Vilken är din prispunkt? Under 100 €/månad behöver du multi-tenant för att vara lönsam. Över 1 000 €/månad blir single-tenant genomförbart.
3. Vilka är efterlevnadskraven? Reglerade branscher kräver ofta starkare isolering.
4. Hur många hyresgäster förväntar du dig? Hundratals eller tusentals hyresgäster behöver delad infrastruktur. Tio till femtio stora hyresgäster kan fungera med dedikerade instanser.
5. Vilken är ditt teams operativa kapacitet? Single-tenant kräver större DevOps-investeringar. Multi-tenant är operativt enklare.

Om du är osäker, börja med multi-tenant med delad databas och säkerhet på radnivå. Det är det billigaste alternativet, det är säkert när det implementeras korrekt, och det håller din arkitektur enkel. Du kan alltid lägga till en dedikerad nivå för enterprise-kunder senare.

Sammanfattning

Det finns ingen universellt korrekt hyresgästmodell. Rätt val beror på dina kunder, din prissättning, dina efterlevnadskrav och din operativa kapacitet.

De flesta SaaS-produkter bör börja med multi-tenant. Det är billigare, enklare och skalar bra. Allteftersom du rör dig uppåt på marknaden och börjar sälja till större organisationer, lägg till single-tenant-alternativ för kunder som behöver dem och är villiga att betala därefter.

Arkitekturen ska tjäna verksamheten, inte tvärtom. Bygg för de kunder du har idag, och designa med tillräcklig flexibilitet för att betjäna de kunder du vill ha imorgon.

---

Behöver du hjälp att välja rätt arkitektur för din SaaS-produkt? Vi har byggt både multi-tenant- och single-tenant-system i flera branscher. Låt oss hitta det bästa tillvägagångssättet för ditt projekt.