RLS im Vergleich zu einer dedizierten Datenbank pro Projekt

Das am häufigsten dokumentierte Muster für Multi-Tenant-Postgres besteht aus drei Zeilen: einer einzelnen Basis, einer tenant_id-Spalte in jeder Tabelle, einer RLS-Richtlinie, die diese Spalte mit einem aus dem JWT extrahierten Wert vergleicht. Es ist wirtschaftlich – ein Pool von Verbindungen, ein Diagramm, eine einzelne Instanz zum Ausführen – und es funktioniert gut, wenn die Mandanten zahlreich und klein sind und der individuelle Anteil gering ist.

Der Kompromiss ist real: Die Grenze zwischen zwei Clients wird zu einem SQL-Ausdruck, der Tabelle für Tabelle ausgewertet wird. Eine in einer neuen Tabelle vergessene Richtlinie, eine Verbindung, die mit einer Superuser-Rolle ausgeführt wird, ein live gestartetes Debug-Skript – jeder dieser Vorfälle, so trivial er auch sein mag, kann stillschweigend die Leitungen aller Mandanten gleichzeitig offenlegen. Die Sicherheitsgrenze und die technische Grenze (die Basis) sind dann genau dasselbe.

Seit einer kürzlichen Konsolidierung des Provisioners (im Code als „Task 12“ gekennzeichnet) fällt ein aktives Postgres-Projekt bei Aurabase unter genau zwei Architekturen – die alten Modelle mit einer tatsächlich von mehreren Projekten gemeinsam genutzten Basis wurden aus dem Provisioning-Pfad entfernt.

pub enum ProjectInstanceKind {
    /// CNPG-Cluster, der NUR DIESEM Projekt gewidmet ist (Unternehmensebene).
    FullyDedicated,

    /// Datenbank zum CNPG-Cluster des Projekts ORGANIZATION —
    /// mit ANDEREN Projekten derSELBEN Organisation geteilt,
    /// niemals mit einer Drittorganisation.
    SharedClusterDedicated,
}

Die Projektebene entscheidet, welche der beiden zutrifft – und es ist der Code, der entscheidet, nicht ein angekreuztes Kästchen in einem Dashboard:

fn should_provision_dedicated(engine: &str, db_url_encrypted: &Option<String>, plan: &str) -> bool {
    matches!(engine, "postgres" | "postgresql")
        && plan == "enterprise"
        && !non_empty(db_url_encrypted)
}

// Should_route_to_fleet(): jede Nicht-Firmen-Stufe (Free/Pro/Team)
// Route zum CNPG-Cluster IHRER EIGENEN Organisation, niemals zu dem einen
// von einer anderen – siehe Migration 073, Konsolidierung auf 2 Architekturen.

On both architectures, the base or cluster never hosts two different organizations — so the question is not “is your data isolated” but “does your project have compute CloudNativePG all to itself, or does it share it with other projects in the same organization.”

Diese Konsolidierung zweier Architekturen ist neu: Der Code trug zuvor zwei zusätzliche Pfade – einen „Shared Master“, bei dem mehrere Projekte in derselben Datenbank koexistierten, nur durch Diagramme isoliert, und eine postgrest_dedicated_shared_db-Variante. Eine dedizierte Migration entfernte sie und verschärfte die Einschränkung der Tabelle projects auf nur die beiden verbleibenden Werte, gerade weil das gemeinsame Schemamodell die Quelle des unten beschriebenen Fehlers war.

Eine separate Postgres-Datenbank ist eine Grenze auf Verbindungsebene, keine Grenze auf Zeilenebene. Eine mit der Datenbank von Projekt A verbundene Anwendungsrolle kann die Tabellen von Projekt B einfach nicht abfragen – für sie ist keine Sitzung geöffnet. Diese Eigenschaft gilt auch dann, wenn eine RLS-Richtlinie schlecht geschrieben ist, in einer Tabelle fehlt oder von einer hohen Rolle umgangen wird: Im schlimmsten Fall bleibt sie auf eine einzelne Datenbank beschränkt.

Auch diese Ablagerung trägt die Spur eines echten Käfers, was das gegenteilige Risiko verdeutlicht. Unter dem alten Shared-Schema-Modell (inzwischen zurückgezogen) gewährte provision_postgres_schema fälschlicherweise GRANT ALL ... TO PUBLIC-Rechte für jedes Projektschema – PUBLIC galt für alle-Rollen in der Datenbank ohne Mitgliedschaftsbedingungen, ein pro Projekt isolierter Login konnte im Schema eines anderen lesen und schreiben. Durch eine korrigierende Migration (066) wurden diese Rechte aus dem bestehenden entfernt.

Ein Patch vom 23. August 2026 geht in die gleiche Richtung: Ein vom Provisioner bedingungslos platzierter REVOKE ALL ON SCHEMA public wurde von der Topologie abhängig gemacht, da er nur auf dem alten Shared-Database-Modell für echte Isolation sorgte – auf den beiden aktuellen Architekturen blockierte er ohne Nutzen den Import von SQL-Dumps, die explizit auf public.<table>verweisen.

Keines der oben genannten Dinge macht EPIRB nutzlos – es verändert nur den Boden. Sobald Sie sich in Ihrer-Projektdatenbank befinden, stellt Aurabase genau die PostgREST-Konvention bereit, die von Supabaseübernommen wurde: drei SQL-Funktionen, die die vom Gateway in request.jwt.claimsfestgelegten JWT-Ansprüche lesen.

create function auth.uid() returns uuid
    language sql stable security definer
    set search_path to 'pg_catalog', 'pg_temp'
    as $$
    select nullif(nullif(current_setting('request.jwt.claims', true), '')::json->>'sub', '')::uuid
$$;

Diese Helfer werden in den eigentlichen Richtlinien von Aurabase selbst verwendet – und nicht nur für Sie dokumentiert. Hier ist die Richtlinie, die storage_objectsschützt, wenn sie im Repository abgelegt wird (zum Lesen in mehrere Zeilen neu formatiert):

alter table storage_objects enable row level security;

create policy storage_objects_select on storage_objects
  for select using (
    (owner_id = auth.uid())
    or (
      exists (
        select 1 from storage_buckets b
        where (b.name = storage_objects.bucket_name and b.public)
      )
    )
  );

In Ihrem eigenen project_<uuid>-Schema, das Ihre Anwendungstabellen enthält, platziert Aurabase bewusst keine Richtlinien in Ihrem Namen – der Code dokumentiert dies als „Supabase-Modell“: Die RLS Ihrer Tabellen liegt weiterhin in Ihrer Verantwortung, mit denselben Funktionen und derselben Syntax.

Postgres bietet nativ ein -Rollenattribut, BYPASSRLS, das alle Richtlinien ignoriert. Aurabase verwendet es freiwillig für zwei Rollenfamilien: aura_service_role (die Serverrolle, die niemals auf der Browserseite verfügbar gemacht wird) und die für jedes Projekt spezifische Verwaltungsrolle, die bei DDL-Vorgängen wie ALTER SCHEMA ... OWNER TOverwendet wird.

create role aura_service_role nologin bypassrls;
-- Serverrolle: niemals auf der Browserseite verfügbar gemacht, niemals Mitglied
-- Rollen aus einem anderen Projekt.

Die Rolle, die Ihre Anfragen bedient anon/authenticated – tenant_<uuid> – hat kein BYPASSRLS: Das RLS gilt ausnahmslos normal für sie. Als Bonus erhalten die für jedes Projekt spezifischen Systemdiagramme (_auth, _storage, _platform) ein aktiviertes RLS ohne Richtlinie – daher standardmäßig eine vollständige Ablehnung für jede Nicht-Bypass-Rolle, eine Tiefenverteidigung für den Fall, dass ein Anwendungspfad eines Tages versehentlich darauf zugreift.

Diese Serverrolle ist Teil eines umfassenderen Ansatzes – vordefinierte Rollen, benutzerdefinierter RBAC, Überwachungsprotokolle –, der auf der Seite Sicherheit und RBACausführlich beschrieben wird.

Auf der SharedClusterDedicated-Ebene koexistieren mehrere Projekte derselben Organisation auf einem einzigen CNPG-Cluster. Die physische Datenbank trennt die Projekte bereits voneinander, aber die PostgreSQL-Rollen – sie – sind globale Objekte für den Cluster, nicht für die Datenbank. Aurabase fügt daher eine Ebene hinzu: ein separates PostgreSQL-Login pro Projekt.

pub fn project_authenticator_role(project_id: &str) -> String {
    format!("project_{}_authenticator", project_id.replace('-', '_'))
}

// Standardmäßig aktiv (F013_PER_PROJECT_AUTHENTICATOR), deaktivierbar
// ausdrücklich als Notflucht.

Jedes Projekt stellt eine Verbindung mit seinem eigenen Login her und ist nur Mitglied seiner eigenen tenant_<uuid> / tenant_<uuid>_admin-Rollen – niemals die eines anderen Projekts im selben Cluster. Die Datenbank isoliert die Daten bereits; Dieser Login pro Projekt isoliert auch die Identität, die eine Verbindung herstellt, sodass ein Vorfall in einem Projekt seinem Login keine Mitgliedschaft verleiht, die er an ein anderes vererben kann.

Die Wahl von Aurabase ist keine universelle Regel – es ist ein Kompromiss für einen bestimmten Fall: die Isolierung von Kunden voneinander, möglicherweise mit unterschiedlichen Compliance-Anforderungen, auf einer Plattform, die sie nicht kontrollieren. Wenn Sie Ihr eigenes SaaS aufbauen, stellt sich für Sie die gleiche Frage, allerdings in einem anderen Maßstab.

• RLS mit tenant_id in einer gemeinsamen Basis – relevant, wenn Ihre Mieter zahlreich sind, einzeln einen geringen Anteil haben und die Kosten einer Basis pro Mieter unverhältnismäßig wären. Testen Sie jede Richtlinie ausnahmslos mit pg_provefür jede Tabelle.
• Dedizierte Basis oder Diagramm – relevant, wenn ein Mandant ein eigenes Compliance-Problem hat (Gesundheit, Personalwesen, öffentlicher Sektor), ein Volumen, das eine Leistungsisolation rechtfertigt, oder die Kosten eines Lecks zwischen zwei bestimmten Clients in keinem Verhältnis zu den Kosten zusätzlicher Infrastruktur stehen würden.

Das Aurabase-Preisniveau wendet dasselbe Schlichtungsverfahren auf seine eigenen Kunden an: standardmäßig gemeinsame Basis durch die Organisation, dedizierter Cluster, wenn die Herausforderung des Projekts dies rechtfertigt. Für RLS-Muster in Ihrer eigenen Datenbank – Besitz, Mandantenfähigkeit nach Organisation, Rollenhierarchie – werden im RLS-Leitfaden in der Produktion die drei Fälle mit pgTAP-Tests detailliert beschrieben. Und wenn Sie die automatisch generierte API in Ihrem Diagramm über REST hinaus interessiert, deckt der Vergleich von pg_graphql mit Hasura und PostGraphile die andere Hälfte der von Aurabase bereitgestellten Postgres-Oberfläche ab.