Eine Multi-Tenant-Architektur bedeutet, dass eine laufende Anwendung viele Kunden, sogenannte Tenants, bedient und dabei die Daten jedes Tenants getrennt hält. Sie ist die Standardbasis von SaaS-Produkten, da alle Kunden denselben Code und dieselbe Infrastruktur nutzen, was die Betriebskosten niedrig hält. Die gestalterische Herausforderung liegt in der gegenseitigen Isolierung der Tenants.
Was ist ein Tenant
Ein Tenant ist ein Kundenkonto, dem eigene Nutzer und Daten gehören, beispielsweise ein Unternehmen, das Ihr Produkt verwendet. Mitarbeiter von Tenant A dürfen niemals Daten von Tenant B sehen, obwohl beide dieselbe Anwendung und oft dieselbe Datenbank nutzen.
Worin liegt der Unterschied zur Single-Tenant-Architektur
Bei einer Single-Tenant-Architektur erhält jeder Kunde eine eigene Deployment-Umgebung. Das bietet starke Isolierung und einfache kundenindividuelle Anpassung, vervielfacht jedoch den Aufwand: Jedes Upgrade, jedes Backup und jeder Vorfall wiederholt sich pro Kunde.
| Multi-Tenant | Single-Tenant | |
|---|---|---|
| Infrastruktur | Gemeinsam genutzt | Pro Kunde |
| Betriebskosten pro Kunde | Niedriger | Höher |
| Upgrades | Einmalig für alle | Pro Kunde |
| Isolierung | Durch Design und Zugriffsregeln | Physisch |
| Anpassbarkeit | Begrenzt, über Einstellungen | Weitreichend |
| Geeignet für | Most SaaS | Strict compliance, large bespoke deals |
What database models are there
Teams usually pick one of three:
- Shared database, shared tables. Every row carries a tenant ID. It is the cheapest and simplest to scale, and it relies on every query filtering correctly.
- Shared database, schema per tenant. Each tenant gets its own schema. Isolation is stronger and migrations get heavier as tenants grow in number.
- Database per tenant. The strongest isolation and the highest cost, often used for large or regulated customers.
Many products start with shared tables and move large customers to their own database later.
How do you keep tenants isolated
Enforce isolation in more than one place. Put the tenant ID in every table and every query path, and add database-level controls such as row level security, so a missed filter in application code does not leak data. Test for it explicitly: write tests that try to read another tenant's data and expect failure. A leak between tenants is among the most damaging bugs a SaaS product can have.
What is the noisy neighbour problem
When tenants share resources, one heavy tenant can slow down the others. Plan for it with rate limits, per-tenant quotas, background job queues with fair scheduling and monitoring that shows load per tenant. Moving a heavy customer to dedicated resources is a normal remedy.
What does it mean for compliance
Shared infrastructure raises questions in security reviews. Larger customers often ask where their data lives, how it is separated and who can access it. Decide early whether you can offer regional hosting, such as EU data residency, or a dedicated deployment for customers who require it. Retrofitting that into a design built around shared tables takes real effort.
Was das für Ihr Entwicklungsteam bedeutet
Tenancy is hard to change once data exists, so the decision deserves a senior engineer's time at the start. AI coding agents can generate queries quickly, and they will happily forget a tenant filter, so isolation tests and database-level controls matter more when agents write code. See how to review AI-generated code for the review habits that catch this.
Backend platforms such as Supabase offer row level security that suits shared-table tenancy. Our vetting puts candidates in a real codebase for two sixty-minute sessions, one with AI tools off and one with their own agents on. To add senior capacity to a SaaS team, see backend engineers, from €5.600 a month for a full-time engineer.
Kurze Antworten
Is multi-tenancy the same as SaaS?
Not exactly. Most SaaS products use multi-tenancy because it lowers cost, but a SaaS product can also run a separate deployment per customer.
Which multi-tenant database model is best?
Shared tables with a tenant ID is simplest and cheapest. Schema or database per tenant gives stronger isolation at higher cost.
Wie verhindern Sie Datenlecks zwischen Mandanten?
Filtern Sie überall nach Mandanten, fügen Sie Kontrollen auf Datenbankebene wie Row Level Security hinzu und schreiben Sie Tests, die versuchen, Mandantengrenzen zu überschreiten.
Kann ich später von Single-Tenant auf Multi-Tenant wechseln?
Ja, aber es handelt sich um eine umfangreiche Änderung an Datenmodellen und Zugriffssteuerung – entscheiden Sie sich daher möglichst frühzeitig.
