Dedizierte vs. gemeinsam genutzte Datenbank: Leistung und Isolation

In der offiziellen Dokumentation von Microsoft zur Architektur von mandantenfähigen SaaS-Anwendungen werden drei Mandantenmodelle unterschieden, die im Allgemeinen als Silo (dedizierte Ressourcen pro Mandant), Pool (vollständig gemeinsam genutzte Ressourcen) und Bridge (eine Mischung aus beiden, einige isolierte Mandanten, andere gemeinsam genutzt) bezeichnet werden. Diese drei Modelle gelten direkt für Postgres, auf Schema-, Datenbank- oder gesamter Clusterebene.

Konkret ergeben sich für ein Postgres-Backend drei unterschiedliche Architekturen. Das gemeinsam genutzte -Schema (eine einzelne Basis, eine tenant_id-Spalte, RLS-Richtlinien, die die Zeilen filtern) ist das am häufigsten verwendete Poolmodell in Leitfäden für mehrere Mandanten: wirtschaftlich, aber die Grenze zwischen zwei Clients wird zu einem SQL-Ausdruck, der Tabelle für Tabelle ausgewertet wird. Die -Basis pro Mandant auf einem gemeinsam genutzten Cluster ist ein Zwischenbrückenmodell: Jeder Mandant hat seine eigene Postgres-Basis (ein echter CREATE DATABASE-Befehl), aber mehrere Basen existieren gleichzeitig auf demselben physischen Cluster und teilen sich daher CPU, E/A und Verbindungen. Der -Cluster, der vollständig pro Mandant dediziert ist, ist das vollständige Silo-Modell: vollständig isolierte CPU-, RAM- und E/A-Ressourcen, im Allgemeinen für Mandanten mit hohen Compliance- oder Lastproblemen reserviert.

Silo-/Pool-/Bridge-Terminologie: offizielle Microsoft-Dokumentation, mehrinstanzenfähige SaaS-Architekturmuster (Azure Architecture Center).

Das Zwischenmodell, Basis pro Mandant auf einem gemeinsam genutzten Cluster, fehlt oft in den Leitfäden, die die Wahl binär zwischen „einer einzigen Basis für alle“ und „ein Server pro Client“ darstellen. Dies ist jedoch diejenige, die Aurabase standardmäßig verwendet (siehe unten).

Die Wahl zwischen diesen drei Modellen ergibt sich bei jeder Entscheidung über eine Multi-Tenant-Architektur, nicht nur bei einem BaaS-Anbieter: Ein Team, das sein eigenes SaaS-Backend auf verwaltetem Postgres aufbaut (RDS, Cloud SQL oder eine selbst gehostete Instanz), führt genau die gleiche Entscheidung durch, wobei dieselben Konfliktmechanismen im Spiel sind, sobald mehrere Clients auf derselben physischen Instanz platziert werden.

Ein noisy neighbor (Noisy Neighbor) ist ein Mandant, der einen unverhältnismäßig großen Anteil der gemeinsam genutzten Ressourcen einer Infrastruktur verbraucht, zum Nachteil anderer Mandanten auf demselben Server. Der Begriff stammt aus der öffentlichen Cloud, bezieht sich aber direkt auf einen gemeinsam genutzten Postgres-Cluster: Eine Datenbank kann die Leistung anderer Datenbanken beeinträchtigen, ohne jemals deren Daten zu berühren.

Sechs Mechanismen kommen in der Produktion am häufigsten vor:

• CPU-Konflikt: Eine teure Abfrage (Join ohne Index, massive Sortierung) verbraucht CPU-Zyklen, die der Kernel zwischen allen aktiven Datenbanken im Cluster teilt.
• IOPS-Konflikt: Eine Sicherung, ein VACUUM FULL oder ein massiver Import überlastet den Festplattendurchsatz des Clusters und verlangsamt Lese- und Schreibvorgänge in anderen Datenbanken.
• Verbindungserschöpfung: max_connections begrenzt die Anzahl der aktiven Verbindungen auf der gesamten Clusterebene, nicht pro Basis. Eine zu weit geöffnete Basis verringert den Spielraum anderer.
• Autovacuum-Konflikt: Autovacuum wird mit einer begrenzten Anzahl von Workern pro Cluster ausgeführt; Eine Datenbank mit einer hohen Schreibrate kann die Bereinigung der Tabellen einer anderen Datenbank verzögern.
• Cache-Räumung: shared_buffers ist ein einzelner Speicher für den gesamten Cluster; Eine Datenbank mit einem großen Arbeitssatz kann die zwischengespeicherten Seiten einer kleineren benachbarten Datenbank entfernen.
• Gemeinsame Wartungsfenster: Backup, Replikat-Failover oder größeres Upgrade gelten für den gesamten Cluster, nicht auf Basis pro Basis.

Strukturdiagramm, kein Messergebnis: Für diese beiden Topologien wurden bisher keine vergleichenden Leistungszahlen veröffentlicht.

Das Verbindungsbudget ist oft das sichtbarste Symptom in der Produktion, noch vor der Latenz. Dies ist das ausführliche Thema unseres max_connections Tuning-Guides und unseres Vergleichs PgBouncer, Supavisor und PgCat.

Ein Transaktionsmodus-Pooler (PgBouncer, Supavisor, PgCat) mildert die Verbindungserschöpfung, beseitigt jedoch keine CPU- oder IOPS-Konflikte: Er verwendet vorhandene Serververbindungen wieder und fügt dem Cluster keine zusätzlichen CPU-Kerne oder Festplattendurchsatz hinzu. Unser -Artikel zum Transaktions-Pooling-Modus beschreibt detailliert, was dieser Modus tatsächlich ändert und was nicht.

Sicherheit auf Zeilenebene löst ein anderes Problem: Sie verhindert, dass eine Abfrage auf logischer Ebene die Zeilen eines anderen Mandanten liest oder ändert. Es reserviert keinen CPU-Zyklus, keinen Verbindungssteckplatz und keinen Festplattendurchsatz für einen bestimmten Mandanten.

Zwei Mieter können vollkommen wasserdichte RLS-Richtlinien haben und sich gleichzeitig gegenseitig herabsetzen: Der laute Nachbar ist ein Problem der physischen Ressourcen, nicht der Zugriffsrechte. Eine Verwechslung der beiden führt zu einem falschen Gefühl der Betriebssicherheit, sobald EPIRB installiert ist.

Der Provisioner-Code (aura-provisioner) dokumentiert genau zwei mögliche Architekturen für ein aktives Postgres-Projekt aus einer Bereitstellungskonsolidierung, die der Code als Aufgabe 12 bezeichnet: FullyDedicated und SharedClusterDedicated. Ältere schemabasierte Modelle wurden aus dem Bereitstellungspfad entfernt.

Die Ebene enterprise löst FullyDedicatedaus: einen gesamten CNPG-Cluster, der für dieses einzelne Projekt reserviert ist. Alle anderen Ebenen (Free, Pro, Team) führen zu SharedClusterDedicated: einer vollwertigen Postgres-project_<uuid>-Datenbank im CNPG-Cluster der Projektorganisation. Es handelt sich daher nicht um ein gemeinsames Schema: Selbst bei einem Standardplan ist Ihre Datenbank eine vollständige Postgres-Datenbank und nicht eine Zeile unter anderen in einer gemeinsamen Tabelle. Geteilt wird der Cluster (CPU, RAM, Festplatte, Verbindungen), nicht die Basis selbst.

Der CNPG-Cluster einer Organisation wird erstellt, wenn ihr erstes Postgres-Projekt bereitgestellt wird, und hostet niemals ein Projekt einer anderen Organisation, eine Designauswahl, die auf Codeebene gesperrt ist (org_cluster.rs, Postgres-Beratungssperre durch die Organisation bei der Erstellung). Der einzig mögliche laute Nachbar auf dem gemeinsamen Aurabase-Landeplatz ist daher ein anderes Projekt Ihrer eigenen Organisation, niemals das eines Drittkunden.

/// Nominale Kapazität (Anzahl der Projektbasen) eines Organisationsclusters.
/// Beobachtbarkeitsschwelle: Richten Sie die Organisation darüber hinaus auf FullyDedicated aus.
/// Steuerbar über FLEET_CLUSTER_CAPACITY (Standard 1000, begrenzt [1, 1_000_000]).
pub fn fleet_cluster_capacity() -> i32 {
    std::env::var("FLEET_CLUSTER_CAPACITY")
        .ok()
        .and_then(|v| v.parse::<i32>().ok())
        .filter(|n| (1..=1_000_000).contains(n))
        .unwrap_or(1000)
}

Aurabase-verwaltete PostgreSQL-Cluster-Architekturspezifikationen.

Dieser Schwellenwert von 1000 Basen pro Cluster ist kein fester Grenzwert: Es handelt sich um einen Beobachtbarkeits-Benchmark, der eine Empfehlung zur Migration zu FullyDedicatedauslöst, nicht um eine automatische Blockierung. Es werden keine Platzierungsentscheidungen mehr getroffen, es ist jetzt nur noch ein Cluster pro Organisation möglich.

Jeder Cluster, ob dediziert oder Flotte, stellt in beiden Topologien einen CNPG-Pooler (PgBouncer) bereit, der einen Teil des Drucks auf aktive Verbindungen absorbiert. Was dieser Pooler tatsächlich für Ressourcenkonflikte ändert, wird unten detailliert beschrieben.

Auch die CPU-/RAM-Größe eines gemeinsam genutzten Clusters ist zwischen Organisationen nicht einheitlich: Sie wird über eine dedizierte Funktion (FleetSizing::from_org_plan, überprüft in org_cluster.rs) von der Ebene der Organisation abgeleitet und nicht von einer einzigen Größe, die auf alle Ebenen angewendet wird. Eine Organisation auf Teamebene dimensioniert ihren Cluster nicht auf die gleiche Weise wie eine Organisation auf freier Ebene.

Diese beiden Architekturen laufen auf PostgreSQL 16, nicht auf Version 17, was in der Docker-Datei des in der Produktion verwendeten CNPG-Images überprüft wird. Diese Wahl der Version hat ihre eigenen Auswirkungen auf die Optimierung, die in unserem Postgres 16 vs. 17 vs. 18-Vergleichdetailliert beschrieben werden.

Für Projekte, die einer vertraglichen Verpflichtung zur dokumentierten physischen Isolierung unterliegen, wird auf unseren Seiten DPA und Compliance detailliert beschrieben, was die einzelnen Ebenen abdecken.

Der Nachteil des Basis-für-Mandanten-Modells, der von mehreren Schema-Migrationsmanagement-Tools wie Bytebase hervorgehoben wird, ist eher betrieblicher als technischer Natur: Jede Migration muss auf jeder Basis einzeln angewendet und überprüft werden, selbst wenn sie im selben Cluster koexistieren. Ein vollständig dedizierter Cluster beseitigt diese Kosten nicht, sondern erhöht sie sogar: eine Migration pro Cluster zur unabhängigen Überwachung und nicht nur eine.

Auf mandantenfähige Softwarearchitektur spezialisierte Ressourcen wie CodeOpinion stellen diesen Zwischenansatz (pro Mandant auf gemeinsam genutzter Infrastruktur) regelmäßig als einen vernünftigen Kompromiss zwischen dem gemeinsam genutzten Schema und dem vollständig dedizierten Cluster dar und nicht als binäre Wahl zwischen den beiden Extremen.

Der Wechsel von Shared zu Dedicated erfordert kein Umschreiben eines Schemas oder einen Wechsel der Engines: In beiden Fällen handelt es sich um Postgres mit derselben pg_dump / pg_restore-Kette wie in unserem Migrationsleitfaden Supabase zu Aurabasebeschrieben. Das Ändern der Ebene bleibt ein Umschaltvorgang und kein Umschreiben der Anwendung.

Eine dedizierte Basis und eine gemeinsam genutzte Basis stehen nicht im Widerspruch zur Datensicherheit: Beide Modelle können einen Mandanten auf logischer Ebene korrekt von einem anderen isolieren. Sie stehen sich in Bezug auf physische Ressourcen (CPU, IOPS, Verbindungen, Cache, Wartungsfenster) gegenüber. Es ist dieser Plan, der einen lauten Nachbarn definiert, nicht eine schlecht geschriebene RLS-Richtlinie.

Das im Bereitstellungscode verifizierte Aurabase-Modell behält standardmäßig einen Zwischenkompromiss bei: eine dedizierte Postgres-Datenbank pro Projekt auf einem gemeinsam genutzten Cluster, die jedoch ausschließlich einer einzelnen Organisation vorbehalten ist, wobei ein vollständig dedizierter Cluster für die Geschäftsebene reserviert ist. Die richtige Wahl hängt von Ihren tatsächlichen Einschränkungen ab und nicht von einem Reflex, bei dem die dedizierte Lösung immer die beste Option wäre.