RLS 与每个项目专用数据库

多租户 Postgres 记录最多的模式由三行组成：单个基础、每个表上的 tenant_id 列、RLS 策略 ，该策略将此列与从 JWT 中提取的值进行比较。它很经济——一个连接池、一个图表、一个运行实例——而且当租户数量众多、规模较小且个人股权较低时，它效果很好。

妥协是真实的：两个客户端之间的边界变成了 SQL 表达式，逐个表进行评估。忘记在新表上的策略、以超级用户角色运行的连接、实时启动的调试脚本 — 这些事件中的每一个，无论操作起来多么微不足道，都可能同时悄悄地暴露所有租户的线路。那么安全边界和技术边界（基础）是完全相同的。

自从最近对配置程序进行了整合（在代码中标记为“任务 12”）以来，Aurabase 中的一个活跃 Postgres 项目恰好属于两种架构 - 具有在多个项目之间实际共享的基础的旧模型已从配置路径中删除。

pub enum ProjectInstanceKind {
    /// CNPG 集群致力于此唯一项目（公司级别）。
    FullyDedicated,

    /// 项目 ORGANIZATION 的 CNPG 集群上的数据库 —
    /// 与同一组织的其他项目共享，
    /// 绝不与第三方组织合作。
    SharedClusterDedicated,
}

项目级别决定了两者中的哪一个适用 - 决定的是代码，而不是仪表板中选中的框：

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()：任何非公司级别（免费/专业/团队）
// 通往您自己组织的 CNPG 集群的路线，而不是唯一的路线
// 来自另一个 — 请参阅迁移 073，整合到 2 种架构。

在这两种架构上，基础或集群永远不会托管两个不同的组织 - 因此问题不是“您的数据是否隔离”，而是“您的项目是否拥有全部计算 CloudNativePG，或者是否与同一组织中的其他项目共享它。”

这种两种架构的整合是最近发生的：之前的代码带有两个额外的路径——一个“共享主”，其中多个项目共存于同一个数据库中，仅通过图表隔离，以及一个 postgrest_dedicated_shared_db变体。专用迁移删除了它们，并将 projects 表的约束收紧为仅剩下的两个值，正是因为共享架构模型是下面描述的错误的根源。

单独的 Postgres 数据库是连接级边界，而不是行级边界。连接到项目 A 数据库的应用程序角色根本无法查询项目 B 的表 — 它没有打开的会话。即使 RLS 策略编写得不好、表中缺失或被高级角色绕过，此属性仍然成立：最坏的情况仍然限制在单个数据库内。

该存款还带有真实错误的痕迹，这说明了相反的风险。在旧的共享模式模型（已撤销）下，provision_postgres_schema 错误地向每个项目模式授予 GRANT ALL ... TO PUBLIC 权限 - PUBLIC 在没有成员资格条件的情况下应用于数据库中的 所有 角色，每个项目隔离的登录可以在另一个项目的模式中读写。纠正性迁移 (066) 从现有权利中删除了这些权利。

2026 年 8 月 23 日的补丁朝着相同的方向发展：由配置者无条件放置的 REVOKE ALL ON SCHEMA public 是在拓扑上有条件的，因为它只在旧的共享数据库模型上提供真正的隔离 - 在当前的两个架构上，它阻止了显式引用 public.<table>的 SQL 转储的导入，但没有任何好处。

上述所有因素都不会导致 EPIRB 毫无用处——它只是改变楼层。一旦进入 您的 项目数据库，Aurabase 就会准确地公开 Supabase所采用的 PostgREST 约定：三个 SQL 函数，它们读取 request.jwt.claims中网关设置的 JWT 声明。

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
$$;

这些助手用于 Aurabase 本身的实际政策中——而不仅仅是为您的政策记录。这是保护 storage_objects的策略，因为它被放置在存储库中（重新格式化为几行以供阅读）：

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)
      )
    )
  );

在您自己的 project_<uuid>模式（承载应用程序表的模式）中，Aurabase 故意不代表您设置任何策略 - 代码将其记录为“Supabase 模型”：表的 RLS 仍然由您负责，具有相同的功能、相同的语法。

Postgres 原生提供 角色属性、 BYPASSRLS，它会忽略所有策略。 Aurabase 自愿在两个角色系列上使用它： aura_service_role （服务器角色，从不在浏览器端公开）和特定于每个项目的管理角色，在 DDL 操作期间使用，如 ALTER SCHEMA ... OWNER TO。

create role aura_service_role nologin bypassrls;
-- 服务器角色：从不暴露在浏览器端，从不是成员
-- 来自另一个项目的角色。

满足您的请求 anon/authenticated — tenant_<uuid> — 的角色没有任何 BYPASSRLS：RLS 通常适用于它，无一例外。作为奖励，特定于每个项目的系统图（_auth、 _storage、 _platform）会收到一个激活的 RLS ，而没有策略 ——因此默认情况下完全拒绝任何非旁路角色，这是一种深度防御，以防有一天应用程序路径错误地访问它。

此服务器角色是更广泛的状态（预定义角色、自定义 RBAC、审核日志）的一部分，详细信息请参见 安全和 RBAC页面。

在 SharedClusterDedicated级别，来自同一组织的多个项目共存于单个 CNPG 集群上。物理数据库已经将项目彼此分开，但 PostgreSQL 角色（它们）是集群的全局对象，而不是数据库的全局对象。因此，Aurabase 添加了一个层：每个项目单独的 PostgreSQL 登录。

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

// 默认处于活动状态 (F013_PER_PROJECT_AUTHENTICATOR)，可停用
// 明确作为紧急逃生。

每个项目都使用自己的登录名进行连接，仅是其自己的 tenant_<uuid> / tenant_<uuid>_admin 角色的成员，而不是同一集群中其他项目的成员。数据库已经隔离了数据；每个项目的登录还隔离了连接到它的身份，因此项目上的事件不会为其登录提供任何继承到另一个项目的成员资格。

Aurabase 的选择并不是通用规则，而是针对特定情况的妥协：在客户无法控制的平台上将客户彼此隔离，可能具有不同的合规性要求。如果您正在构建自己的 SaaS，您也会遇到同样的问题，只是规模不同。

• RLS 与 tenant_id 位于共享基地 中 — 当您的租户众多、个体风险较低且每个租户的基地成本不成比例时，此方法非常有用。在每个表上使用 pg_prove测试每个策略，无一例外。
• 专用基础或图表 — 每当租户有自己的合规问题（健康、人力资源、公共部门）、证明性能隔离合理的卷或两个特定客户端之间的泄漏成本与额外基础设施的成本不成比例时，相关的。

Aurabase 定价水平对其自己的客户应用相同的仲裁：默认情况下由组织共享基础，当项目的挑战证明其合理时专用集群。对于您自己的数据库内的 RLS 模式（所有权、组织多租户、角色层次结构），生产环境中的 RLS 指南 详细介绍了 pgTAP测试的三种情况。如果您对图表上自动生成的 API 感兴趣而超出了 REST，那么 pg_graphql 与 Hasura 和 PostGraphile 的比较涵盖了 Aurabase 暴露的 Postgres 表面的另一半。