Compatibilidade PostgREST: o que cobre e alternativas

PostgREST é um servidor web autônomo que transforma um banco de dados PostgreSQL existente em uma API REST, diretamente de seu esquema. Nenhuma camada de aplicação para escrever: tabelas, visualizações e funções tornam-se rotas, e permissões SQL — funções, políticas RLS — tornam-se a camada de autorização.

Concretamente, o PostgREST abrange cinco capacidades que surgem em quase todas as avaliações:

• Filtragem horizontal - cerca de trinta operadores (eq, gt, like, ilike, in, is, cs, ov, fts...) diretamente na string de consulta.
• Filtragem vertical e incorporação — ?select= projeta colunas e incorpora relacionamentos por meio de chave estrangeira, por exemplo customer:customers(email).
• RPC — um POST /rpc/{fonction} chama diretamente uma função SQL, que se torna um endpoint.
• RLS conduzido por JWT — PostgREST alterna a função ativa do Postgres de acordo com o token recebido (SET LOCAL ROLE), para que suas políticas sejam aplicadas como estão, sem lógica de autorização duplicada no lado do aplicativo.
• OpenAPI autogerado — a especificação é deduzida do esquema exposto, sem um arquivo para manter manualmente.

curl "https://<gateway>/v1/db/<project_id>/orders \
  ?select=id,total,customer:customers(email) \
  &status=eq.paid \
  &order=created_at.desc" \
  -H "apikey: <votre-cle-api>"

Uma única solicitação HTTP filtra os pedidos pagos, incorpora o e-mail do cliente por meio de chave estrangeira e classifica por data — sem que uma única rota precise ser escrita à mão.

O RPC segue a mesma lógica: uma função SQL já escrita em seu banco de dados torna-se um endpoint POST, com seus argumentos passados em JSON.

curl -X POST "https://<gateway>/v1/db/<project_id>/rpc/monthly_revenue" \
  -H "apikey: <votre-cle-api>" \
  -H "Content-Type: application/json" \
  -d '{"year": 2026, "month": 8}'

Este princípio — o esquema Postgres é a única fonte de verdade da API — é o que torna o PostgREST previsível: toda mudança de comportamento passa por uma migração SQL, nunca por uma camada de aplicativo separada que poderia derivar do esquema real. O projeto é de código aberto, desenvolvido em GitHub, independente de qualquer provedor de BaaS específico.

PostgREST resolve a camada CRUD. Isso não resolve o restante do back-end de um aplicativo. Quatro deficiências ocorrem sistematicamente entre as equipes que o adotam sozinhas.

• Autenticação — sem emissão de JWT ou gerenciamento integrado de usuários. Você deve construí-lo em SQL ou delegá-lo a um serviço externo.
• Armazenamento de arquivo — nenhum. Um bucket S3 ou equivalente ainda precisa ser conectado separadamente.
• Tempo real — PostgREST responde a solicitações HTTP únicas, não envia nenhum evento.
• Connection Pooler — O próprio PostgREST se conecta ao Postgres, mas não integra nenhum pooler avançado. Em escala, gerenciá-lo torna-se uma decisão operacional por si só: um pooler no modo de transação clássico entra em conflito com o mecanismo de recarregamento do esquema PostgREST (veja abaixo como o Aurabase resolve esse comprometimento).

Uma consequência prática merece ser declarada claramente: sem autenticação, as suas políticas de RLS tornam-se a única fronteira de segurança entre um cliente anónimo e os seus dados. Uma política mal escrita sobre a função anon não é substituída por uma camada de aplicação adicional – não existe nenhuma.

Em um projeto de mecanismo Aurabase Postgres — o mecanismo padrão — o gateway roteia cada solicitação CRUD diretamente para uma instância PostgREST v12.2.8 dedicada a este projeto, duas réplicas, co-localizadas com o cluster Postgres do locatário. Esta não é uma compatibilidade aproximada: é o próprio binário upstream do PostgREST, com os mesmos operadores, a mesma incorporação, o mesmo RPC, o mesmo RLS conduzido por JWT.

Em um projeto de mecanismo MongoDB, a história é diferente. O MongoDB não tem equivalente ao PostgREST: essas solicitações são roteadas para um serviço interno do Aurabase, que reimplementa um subconjunto das mesmas convenções — nomes de operadores idênticos, sintaxe ?select= com incorporação, cabeçalhos Prefer e Content-Range — mas em um mecanismo de documento, não relacional. Esta camada tem suas próprias limitações: uma incorporação solicitada na representação retornada por uma mutação é explicitamente negada em vez de ignorada silenciosamente, e não há rota RPC equivalente às funções SQL.

Um detalhe técnico contrasta com a intuição: cada instância PostgREST dedicada permanece diretamente conectada ao Postgres primário, sem passar pelo pooler PgBouncer implantado para este locatário. Razão suposta: o modo de pool de transações interromperia o recarregamento do esquema PostgREST, que depende de LISTEN/NOTIFY — uma conexão persistente, incompatível com um pool que recicla a conexão para cada transação.

Outro detalhe útil na produção: um projeto inativo pode ser pausado para economizar recursos. A primeira solicitação em um projeto inativo aciona sua ativação e recebe um 503 com um atraso de nova tentativa, o tempo para a instância dedicada do PostgREST voltar a funcionar — um compromisso assumido entre custo e latência fria, não um incidente oculto.

O PostgREST tem um uso claro: o esquema Postgres é a fonte da verdade e a equipe deseja evitar escrever uma camada CRUD manualmente. Além deste caso específico, existem várias famílias de alternativas dependendo do que você deseja adicionar - desde nada (simples auto-hospedado) até um backend completo pronto para uso.

A tabela abaixo compara o que cada opção cobre nativamente e o que ela deixa explicitamente a seu critério — sem julgamento de valor sobre a arquitetura escolhida por cada projeto.

Um ponto muitas vezes subestimado na escolha de “auto-hospedado”: o próprio PostgREST permanece leve para rodar, mas a operação de produção (atualização de versão, alta disponibilidade, associação com pooler, monitoramento) permanece inteiramente de sua responsabilidade – é esse trabalho de operação, e não o software, que as plataformas gerenciadas absorvem.

Para uma comparação detalhada entre as abordagens GraphQL - pg_graphql, Hasura e PostGraphile - consulte nosso artigo dedicado à API GraphQL no Postgres.

Quatro situações surgem com mais frequência. A escolha certa depende principalmente do que você está disposto a montar e manter.

• Você deseja apenas uma API REST sobre um esquema Postgres existente, nada mais. PostgREST auto-hospedado é suficiente: ele faz exatamente o que faz e nada mais precisa ser instalado.
• Você precisa de autenticação adicional, armazenamento e tempo real e está pronto para montar vários serviços. Supabase, ou PostgREST acompanhado de sua própria pilha de aplicativos, atende a essa necessidade.
• Você prefere GraphQL a REST. Hasura ou PostGraphile cobrem esse terreno - uma escolha arquitetônica diferente, não um substituto direto para PostgREST.
• Você deseja um back-end completo do Postgres sem unir vários serviços separados. Este é o ângulo que nossa arquitetura Rust unificada documenta: PostgREST real para a camada CRUD, nativamente cercado por funções de autenticação, armazenamento, tempo real e borda.