Toegewijde versus gedeelde database: prestaties en isolatie

In de officiële documentatie van Microsoft over de architectuur van SaaS-applicaties met meerdere tenants worden drie huurmodellen onderscheiden, doorgaans Silo (toegewijde bronnen per tenant), Pool (volledig gedeelde bronnen) en Bridge (een combinatie van de twee, sommige geïsoleerde tenants, andere gedeeld). Deze drie modellen zijn rechtstreeks van toepassing op Postgres, op schema-, database- of volledig clusterniveau.

Concreet levert dit voor een Postgres-backend drie verschillende architecturen op. Het gedeelde schema (een enkele basis, een kolom tenant_id, RLS-beleid dat de rijen filtert) is het meest voorkomende poolmodel in handleidingen voor meerdere tenants: economisch, maar de grens tussen twee clients wordt een SQL-expressie die tabel voor tabel wordt geëvalueerd. De -basis per tenant op een gedeeld cluster is een tussenliggend Bridge-model: elke tenant heeft zijn eigen Postgres-basis (een echte CREATE DATABASE-opdracht), maar er bestaan ​​verschillende bases naast elkaar op hetzelfde fysieke cluster, waardoor CPU, IO en verbindingen worden gedeeld. Het cluster, volledig toegewijd per tenant,, is het complete Silo-model: volledig geïsoleerde CPU-, RAM- en IO-bronnen, doorgaans gereserveerd voor tenants met hoge compliance- of belastingsproblemen.

Silo / Pool / Bridge-terminologie: officiële Microsoft-documentatie, SaaS-architectuurpatronen met meerdere tenants (Azure Architecture Center).

Het tussenmodel, basis per tenant op een gedeeld cluster, ontbreekt vaak in de handleidingen die de keuze als binair presenteren tussen “één enkele basis voor iedereen” en “één server per client”. Dit is echter degene die Aurabase standaard gebruikt, zoals hieronder beschreven.

De keuze tussen deze drie modellen ontstaat bij elke multi-tenant architectuurbeslissing, en niet alleen bij een BaaS-provider: een team dat zijn eigen SaaS-backend bouwt op beheerde Postgres (RDS, Cloud SQL of een zelf-gehoste instantie) maakt precies dezelfde arbitrage, waarbij dezelfde conflictmechanismen in het spel zijn zodra meerdere clients op dezelfde fysieke instantie worden geplaatst.

Een noisy neighbor (luidruchtige buur) is een tenant die een onevenredig groot deel van de gedeelde bronnen van een infrastructuur verbruikt, ten koste van andere tenants op dezelfde server. De term komt uit de publieke cloud, maar is rechtstreeks van toepassing op een gedeeld Postgres-cluster: de ene database kan de prestaties van andere databases verslechteren zonder ooit hun gegevens aan te raken.

Zes mechanismen komen het vaakst voor in de productie:

• CPU-conflict: een dure query (join zonder index, massale sortering) verbruikt CPU-cycli die de kernel deelt tussen alle actieve databases in het cluster.
• IOPS-conflict: een back-up, een VACUUM FULL of een enorme import verzadigt de schijfdoorvoer van het cluster, waardoor het lezen en schrijven naar andere databases wordt vertraagd.
• Uitputting van verbindingen: max_connections beperkt het aantal actieve verbindingen op het gehele clusterniveau, niet per basis. Een basis die te ver opengaat, verkleint de marge van anderen.
• Autovacuümconflict: autovacuüm wordt uitgevoerd met een beperkt aantal werkers per cluster; een database met een hoge schrijfsnelheid kan het opschonen van de tabellen van een andere database vertragen.
• Cache-verwijdering: shared_buffers is één geheugen voor het hele cluster; een database met een grote werkset kan de in de cache opgeslagen pagina's van een kleinere aangrenzende database verwijderen.
• Gedeelde onderhoudsvensters: back-up, replica-failover of grote upgrade zijn van toepassing op het gehele cluster, niet per basis.

Structuurdiagram, geen meetresultaat: tot nu toe zijn er voor deze twee topologieën geen vergelijkende prestatiecijfers gepubliceerd.

Verbindingsbudget is vaak het meest zichtbare symptoom in productie, zelfs vóór de latentie. Dit is het gedetailleerde onderwerp van onze max_connections afstemmingsgids en onze vergelijking PgBouncer, Supavisor en PgCat.

Een pooler in transactiemodus (PgBouncer, Supavisor, PgCat) vermindert de uitputting van de verbinding, maar neemt de CPU- of IOPS-conflicten niet weg: het hergebruikt bestaande serververbindingen, het voegt geen extra CPU-kernen of schijfdoorvoer toe aan het cluster. Ons artikel over de transactiepoolingmodus legt uit wat deze modus feitelijk verandert, en wat deze niet verandert.

Row-Level Security lost een ander probleem op: het voorkomt dat een query de rijen van een andere tenant leest of wijzigt, op logisch niveau. Er wordt geen CPU-cyclus, geen verbindingsslot en geen schijfdoorvoer gereserveerd voor een specifieke tenant.

Twee huurders kunnen een perfect waterdicht RLS-beleid hebben en elkaar tegelijkertijd degraderen: de luidruchtige buurman is een probleem van fysieke bronnen, niet van toegangsrechten. Het verwarren van deze twee leidt tot een vals gevoel van operationele veiligheid zodra EPIRB is geïnstalleerd.

De provisionercode (aura-provisioner) documenteert precies twee mogelijke architecturen voor een actief Postgres-project, vanuit een provisioningconsolidatie waarnaar de code verwijst als Taak 12: FullyDedicated en SharedClusterDedicated. Verouderde, op schema gebaseerde modellen zijn verwijderd uit het inrichtingspad.

Het niveau enterprise activeert FullyDedicated: een volledig CNPG-cluster, gereserveerd voor dit enkele project. Alle andere niveaus (gratis, pro, team) leiden naar SharedClusterDedicated: een volwaardige Postgres project_<uuid>-database, op de CNPG-cluster van de projectorganisatie. Het is daarom geen gedeeld schema: zelfs bij een standaardabonnement is uw database een complete Postgres-database, niet één regel onder andere in een gemeenschappelijke tabel. Wat wordt gedeeld is het cluster (CPU, RAM, schijf, verbindingen), niet de basis zelf.

Het CNPG-cluster van een organisatie wordt gemaakt wanneer het eerste Postgres-project wordt ingericht en host nooit een project van een andere organisatie, een ontwerpkeuze die is vergrendeld op codeniveau (org_cluster.rs, Postgres-adviesvergrendeling per organisatie bij creatie). De enige mogelijke luidruchtige buurman op de gedeelde Aurabase-overloop is dus een ander project van uw eigen organisatie, nooit dat van een externe opdrachtgever.

/// Nominale capaciteit (aantal projectbases) van een organisatiecluster.
/// Waarneembaarheidsdrempel: stuur de organisatie verder richting FullyDedicated.
/// Bestuurbaar via FLEET_CLUSTER_CAPACITY (standaard 1000, beperkt [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 beheerde PostgreSQL-clusterarchitectuurspecificaties.

Deze drempel van 1000 bases per cluster is geen harde limiet: het is een observatiebenchmark die een aanbeveling activeert om naar FullyDedicatedte migreren, en niet een automatische blokkering. Het stuurt geen plaatsingsbeslissingen meer, er is nu slechts één cluster per organisatie mogelijk.

Elke cluster, dedicated of vloot, beschikt over een CNPG Pooler (PgBouncer) die een deel van de druk op actieve verbindingen absorbeert, in beide topologieën. Wat deze pooler feitelijk verandert voor de strijd om hulpbronnen, wordt hieronder gedetailleerd beschreven.

De CPU/RAM-grootte van een gedeeld cluster is ook niet uniform tussen organisaties: deze wordt afgeleid van het niveau van de organisatie via een speciale functie (FleetSizing::from_org_plan, geverifieerd in org_cluster.rs), en niet van één enkele grootte die op alle niveaus wordt toegepast. Een organisatie op teamniveau schaalt haar cluster niet op dezelfde manier in als een organisatie op vrij niveau.

Deze twee architecturen draaien op PostgreSQL 16, niet op versie 17, geverifieerd in de Dockerfile van de CNPG-image die bij de productie wordt gebruikt. Deze versiekeuze heeft zijn eigen afstemmingsimplicaties, gedetailleerd in onze Postgres 16 vs 17 vs 18 vergelijking.

Voor projecten die onderworpen zijn aan een contractuele verplichting voor gedocumenteerde fysieke isolatie, geven onze pagina's DPA en naleving pagina's aan wat elk niveau omvat.

De keerzijde van het base-by-tenant-model, benadrukt door verschillende beheertools voor schemamigratie, zoals Bytebase, is eerder operationeel dan technisch: elke migratie moet op elke basis worden toegepast en geverifieerd, één voor één, zelfs als ze naast elkaar op hetzelfde cluster bestaan. Een volledig dedicated cluster elimineert deze kosten niet, maar voegt ze zelfs toe: één migratie per cluster om onafhankelijk te monitoren, in plaats van slechts één.

Bronnen die gespecialiseerd zijn in softwarearchitectuur voor meerdere huurders, zoals CodeOpinion, presenteren deze tussenliggende benadering (per huurder op basis van gedeelde infrastructuur) regelmatig als een redelijk compromis tussen het gedeelde schema en het volledig toegewijde cluster, in plaats van een binaire keuze tussen de twee uitersten.

Om van gedeeld naar dedicated te gaan, is het niet nodig om een schema te herschrijven of de engine te wijzigen: in beide gevallen is het Postgres, met dezelfde pg_dump / pg_restore-keten als beschreven in onze Supabase naar Aurabase-migratiehandleiding. Het wijzigen van het niveau blijft een schakelhandeling, geen herschrijven van een applicatie.

Dedicated base en shared base conflicteren niet op het gebied van gegevensbeveiliging: beide modellen kunnen de ene tenant op logisch niveau correct van de andere isoleren. Ze staan ​​tegenover elkaar op fysieke bronnen (CPU, IOPS, verbindingen, cache, onderhoudsvensters). Het is dit plan dat een luidruchtige buur definieert, en niet een slecht geschreven RLS-beleid.

Het Aurabase-model, geverifieerd in de provisioner-code, behoudt standaard een tussenliggend compromis: een speciale Postgres-database per project, op een gedeeld cluster, maar strikt gereserveerd voor één enkele organisatie, met een volledig speciaal cluster gereserveerd voor het bedrijfsniveau. De juiste keuze hangt af van uw werkelijke beperkingen, niet van een reflex waarbij toegewijd altijd de beste optie zou zijn.