Multi-tenant betyder, at alle kunder deler samme kørende system, og at softwaren holder dem adskilt. Single tenant betyder, at hver kunde har sin egen installation. For de fleste SaaS-produkter er multi-tenant det rigtige udgangspunkt, fordi I kun skal drive, opdatere og overvåge én ting. Én installation pr. kunde giver stærkere adskillelse og ro over for krævende kunder, og den koster tilsvarende mere arbejde pr. kunde. Valget er svært at omgøre, så det bør træffes med åbne øjne, helst før den første store kunde stiller krav.
De to modeller, og det, der ligger imellem
Tænk på en boligblok og et parcelhuskvarter. I blokken deles fundament, rør og tag, og hver lejlighed har sin egen dør. Vedligeholdelse sker ét sted, og alle får det samme. I kvarteret har hver familie sit eget hus. Mere privatliv, og hver tagrende skal renses for sig.
Der findes flere trin imellem, og valget er sjældent enten eller:
- Delte tabeller. Alle kunders data ligger i samme tabeller og er mærket med et kunde-id. Billigst at drive, og det kræver mest disciplin i koden.
- Delt database med adskilte områder. Hver kunde har sit eget område i samme database.
- Egen database pr. kunde, samme kode. Data er adskilt tydeligt, mens softwaren er fælles.
- Fuld installation pr. kunde. Alt er adskilt, ofte også i eget driftsmiljø.
Opdatering og drift
Her er forskellen størst. I en multi-tenant-løsning rammer en udgivelse alle på én gang. Rettelser når alle kunder med det samme, og I har kun ét system at holde øje med. Til gengæld rammer en fejl også alle på én gang, så test og trinvis udrulning betyder mere.
Ved én installation pr. kunde vokser arbejdet med antallet af kunder. Hver opdatering skal rulles ud mange gange, og uden god automatik ender kunderne på forskellige versioner. Så er vejen kort til det, der er beskrevet i når hver kunde har sin version. Skal modellen fungere, må hver installation kunne oprettes og opdateres automatisk, og alle skal køre samme version.
Adskillelse og sikkerhed
Ved delte tabeller er koden det eneste, der holder kunderne fra hinanden. Glemmer en forespørgsel at filtrere på kunde, kan data løbe over. Det kan bygges forsvarligt, med adskillelsen lagt ét sted i koden eller håndhævet af databasen selv, så en enkelt udvikler ikke kan glemme det. Men det skal være en bevidst beslutning, og det skal testes hver gang, der ændres noget.
Én installation pr. kunde gør den fejltype langt mindre sandsynlig. Den fjerner ikke andre risici, og I får flere miljøer at holde opdaterede og flere steder, en glemt opsætning kan gemme sig.
Når én kunde belaster de andre
I et delt system kan en stor kunde med en tung rapport gøre produktet langsomt for alle. Fagordet er “noisy neighbor”. Det løses med grænser for forbrug og ved at køre tunge job for sig, og det er uddybet i produktet er blevet langsomt. Oplever I det tit, er det et tegn på, at de største kunder måske skal have egne ressourcer, selv om softwaren er fælles.
Kundernes krav
Krævende kunder spørger ofte, om deres data er adskilt fra andres. Nogle vil have data i en bestemt region, egne krypteringsnøgler eller en dedikeret installation. Tag stilling, før salget svarer:
- Hvad betyder adskillelse hos os helt konkret, forklaret på en halv side?
- Kan vi flytte én kunde til en anden region?
- Kan vi genskabe én kundes data uden at røre de andre? Det spørgsmål er gennemgået i kan I genskabe produktet.
- Kan vi eksportere og slette alle data for én kunde?
Det sidste spørgsmål har også en regelside. Dataforordningen, også kaldet Data Act, kræver af udbydere af SaaS, at kundens data kan eksporteres i et struktureret, maskinlæsbart format på anmodning. Set fra arkitekturen betyder det, at det skal være let at trække præcis én kundes data ud. Reglerne er beskrevet i jeres SaaS skal kunne forlades.
Beskrivelsen af adskillelsen er god at have på hylden, og den passer ind i arkitekturbeskrivelsen på tre sider.
Sådan vælger I
Disse spørgsmål afgør det i de fleste tilfælde:
- Hvor mange kunder regner I med? Mange små kunder trækker mod multi-tenant, få meget store kan bære egne installationer.
- Hvor følsomme er data? Stærkt regulerede kunder kan kræve mere adskillelse.
- Hvor stort er driftsteamet? Et lille team kan ikke passe mange installationer uden automatik.
- Skal kunderne have særlige versioner? Det bør de ikke. Vil de alligevel, så løs det med indstillinger.
Mange ender med en blanding: fælles software og en fælles database for de fleste, og egen database for de få største kunder. Det virker bedst, når koden er bygget, så forskellen ligger i opsætningen.
Skriv valget ned, og læg det i produktets faste grundlag. Det påvirker prissætning, salg og support, så det er en beslutning for ledelsen, som teknologien skal belyse. Se også andre valg, der er svære at omgøre.
Det skal I lade være med
· At love en stor kunde egen installation for at lukke en aftale, uden at regne driften med. Den ene undtagelse bliver til en fast opgave.
· At lade hver udvikler selv filtrere på kunde. Læg adskillelsen ét sted, og test den.
· At lade kunderne køre forskellige versioner. Det er begyndelsen på en lang række særaftaler.
· At vente med beslutningen, til systemet er fyldt. At adskille data bagefter er et stort stykke arbejde.
Det skal I kræve af den eksterne
- ☐ En anbefaling af model ud fra kunder, data og team.
- ☐ En beskrivelse af adskillelsen, som en kunde kan læse.
- ☐ Test, der viser, at data ikke løber mellem kunder.
- ☐ Et svar på, hvordan én kundes data kan eksporteres, genskabes og slettes.
- ☐ En plan for de kunder, der ikke passer ind i standardmodellen.
Kilder
- Digitaliseringsstyrelsen: Databehandlingstjenester (cloudtjenester): reglerne om skift og eksport.
- Europa-Kommissionen: The Data Act explained.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Den store kunde kræver SSO, logning og roller · Monolit eller microservices
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
