RLS vs um banco de dados dedicado por projeto

O padrão mais documentado para Postgres multilocatário consiste em três linhas: uma única base, uma coluna tenant_id em cada tabela, uma política RLS que compara esta coluna a um valor extraído do JWT. É econômico – um conjunto de conexões, um diagrama, uma única instância para executar – e funciona bem quando os inquilinos são numerosos, pequenos e de baixa participação individual.

O compromisso é real: o limite entre dois clientes torna-se uma expressão SQL , avaliada tabela por tabela. Uma política esquecida em uma nova tabela, uma conexão em execução com uma função de superusuário, um script de depuração lançado ao vivo — cada um desses incidentes, por mais trivial que seja em operação, pode expor silenciosamente as linhas de todos os inquilinos ao mesmo tempo. A fronteira de segurança e a fronteira técnica (a base) são então exactamente a mesma coisa.

Desde uma recente consolidação do provisionador (marcado no código como "Tarefa 12"), um projeto Postgres ativo no Aurabase se enquadra exatamente em duas arquiteturas - os modelos antigos com uma base realmente compartilhada entre vários projetos foram removidos do caminho de provisionamento.

pub enum ProjectInstanceKind {
    /// Cluster CNPG dedicado a ESTE SÓ projeto (nível de empresa).
    FullyDedicated,

    /// Base de dados do cluster CNPG do projeto ORGANIZAÇÃO —
    ///compartilhado com OUTROS projetos da MESMA organização,
    /// nunca com uma organização terceirizada.
    SharedClusterDedicated,
}

O nível do projeto decide qual dos dois se aplica — e é o código que decide, não uma caixa marcada em um painel:

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(): qualquer nível que não seja da empresa (gratuito/profissional/equipe)
// rota para o cluster CNPG da SUA PRÓPRIA organização, nunca aquela
// de outro — veja migração 073, consolidação para 2 arquiteturas.

Em ambas as arquiteturas, a base ou cluster nunca hospeda duas organizações diferentes — portanto, a questão não é “seus dados estão isolados”, mas “seu projeto tem computação CloudNativePG só para si ou os compartilha com outros projetos na mesma organização”.

Esta consolidação de duas arquiteturas é recente: o código anteriormente carregava dois caminhos adicionais – um “mestre compartilhado” onde vários projetos coexistiam em um mesmo banco de dados, isolados apenas por diagrama, e uma variante postgrest_dedicated_shared_db. Uma migração dedicada os removeu e reforçou a restrição da tabela projects para apenas os dois valores restantes, precisamente porque o modelo de esquema compartilhado foi a origem do bug descrito abaixo.

Um banco de dados Postgres separado é um limite no nível da conexão, não um limite no nível da linha. Uma função de aplicativo conectada ao banco de dados do projeto A simplesmente não pode consultar as tabelas do projeto B — ela não possui uma sessão aberta para ela. Esta propriedade é válida mesmo se uma política RLS estiver mal escrita, faltando em uma tabela ou ignorada por uma função elevada: o pior caso permanece confinado em um único banco de dados.

Este depósito também traz vestígios de um bug real que ilustra o risco oposto. No antigo modelo de esquema compartilhado (já retirado), provision_postgres_schema concedeu por engano direitos GRANT ALL ... TO PUBLIC a cada esquema de projeto - PUBLIC aplicando a todas as funções no banco de dados sem condições de associação, um login isolado por projeto poderia ler e gravar no esquema de outro. Uma migração corretiva (066) removeu esses direitos do existente.

Um patch de 23 de agosto de 2026 vai na mesma direção: um REVOKE ALL ON SCHEMA public colocado incondicionalmente pelo provisionador foi tornado condicional à topologia, porque só fornecia isolamento real no antigo modelo de banco de dados compartilhado — nas duas arquiteturas atuais, bloqueava sem benefício a importação de dumps SQL que referenciam explicitamente public.<table>.

Nenhuma das opções acima torna o EPIRB inútil – ele apenas muda de piso. Uma vez em seu banco de dados do projeto, Aurabase expõe exatamente a convenção PostgREST adotada por Supabase: três funções SQL que leem as declarações JWT definidas pelo gateway em request.jwt.claims.

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

Esses auxiliares são usados nas políticas reais do próprio Aurabase - não apenas documentadas para as suas. Aqui está a política que protege storage_objects, conforme ela é colocada no repositório (reformatada em diversas linhas para leitura):

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

Em seu próprio esquema project_<uuid>, aquele que carrega suas tabelas de aplicação, o Aurabase deliberadamente não coloca nenhuma política em seu nome — o código o documenta como um “modelo Supabase”: o RLS de suas tabelas permanece de sua responsabilidade, com as mesmas funções, a mesma sintaxe.

O Postgres oferece nativamente um atributo de função , BYPASSRLS, que ignora todas as políticas. Aurabase o utiliza voluntariamente em duas famílias de funções: aura_service_role (a função de servidor, nunca exposta no lado do navegador) e a função de administração específica para cada projeto, usada durante operações DDL como ALTER SCHEMA ... OWNER TO.

create role aura_service_role nologin bypassrls;
-- Função de servidor: nunca exposta no lado do navegador, nunca é membro
-- funções de outro projeto.

A função que atende suas solicitações anon/authenticated — tenant_<uuid> — não possui nenhum BYPASSRLS: o RLS se aplica a ela normalmente, sem exceção. Como bônus, os diagramas de sistema específicos para cada projeto (_auth, _storage, _platform) recebem um RLS ativado sem política — portanto, uma recusa total por padrão para qualquer função não-bypass, uma defesa profunda caso um caminho de aplicativo o acesse um dia por engano.

Essa função de servidor faz parte de uma postura mais ampla — funções predefinidas, RBAC personalizado, logs de auditoria — detalhada na página Segurança e RBAC.

No nível SharedClusterDedicated, vários projetos da mesma organização coexistem em um único cluster CNPG. O banco de dados físico já separa os projetos uns dos outros, mas as funções do PostgreSQL — elas — são objetos globais para o cluster, não para o banco de dados. Aurabase, portanto, adiciona uma camada: um login PostgreSQL separado por projeto.

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

// Ativo por padrão (F013_PER_PROJECT_AUTHENTICATOR), desativável
// explicitamente como uma fuga de emergência.

Cada projeto se conecta com seu próprio login, membro apenas de suas próprias funções tenant_<uuid> / tenant_<uuid>_admin — nunca aquelas de outro projeto no mesmo cluster. O banco de dados já isola os dados; Esse login por projeto também isola a identidade que se conecta a ele, de modo que um incidente em um projeto não dê ao seu login nenhuma associação para herdar de outro.

A escolha da Aurabase não é uma regra universal — é um compromisso para um caso específico: isolar clientes uns dos outros, potencialmente com requisitos de conformidade diferentes, numa plataforma que não controlam. Se você está construindo seu próprio SaaS, a mesma pergunta surge para você, em uma escala diferente.

• RLS com tenant_id em base compartilhada — relevante quando seus locatários são numerosos, individualmente de baixa participação, e o custo de uma base por locatário seria desproporcional. Teste cada política com pg_prove, em cada tabela, sem exceção.
• Base ou diagrama dedicado — relevante sempre que um inquilino tem seu próprio problema de conformidade (saúde, RH, setor público), um volume que justifica o isolamento de desempenho ou o custo de um vazamento entre dois clientes específicos seria desproporcional ao custo de infraestrutura adicional.

O nível de preços Aurabase aplica esta mesma arbitragem aos seus próprios clientes: base partilhada por organização por defeito, cluster dedicado quando o desafio do projecto o justifica. Para padrões RLS dentro de seu próprio banco de dados — propriedade, multilocatário por organização, hierarquia de funções — o guia RLS em produção detalha os três casos com testes pgTAP. E se a API gerada automaticamente em seu diagrama lhe interessa além do REST, a comparação em pg_graphql versus Hasura e PostGraphile cobre a outra metade da superfície Postgres exposta pelo Aurabase.