Supabase vs PostgreSQL Autogerenciado vs Aurora: Como Escolher

Toda decisão de "onde roda o banco" é, na prática, uma decisão arquitetural disfarçada de decisão de custo. Supabase, PostgreSQL autogerenciado (on-premise ou em uma VM/EC2) e um DBaaS como Amazon Aurora resolvem o mesmo problema — persistência relacional — com trade-offs bem diferentes em controle, operação e superfície de risco. Este post compara os três modelos nos pontos que mais pesam no dia a dia de quem sustenta o ambiente depois que ele já está em produção.

O que cada opção realmente é ?

PostgreSQL autogerenciado: você instala, configura e opera o PostgreSQL diretamente — seja em servidor físico, VM on-premise ou uma instância EC2/Compute genérica. Controle total sobre postgresql.conf, extensões, versão do kernel, storage e rede. Responsabilidade total também.

Supabase: uma plataforma construída sobre PostgreSQL que adiciona uma camada de produto — Auth, Storage, Realtime (via replicação lógica), Edge Functions e uma API REST/GraphQL autogerada a partir do schema (PostgREST). Por baixo, é Postgres gerenciado, mas o valor central do produto está nessa camada de aplicação em torno do banco, não apenas na operação do banco em si.

Amazon Aurora (PostgreSQL-Compatible): um DBaaS de infraestrutura da AWS. Não adiciona camada de produto (Auth, Storage etc.) — o foco é ser um motor relacional compatível com PostgreSQL, com uma arquitetura de storage distribuído própria da AWS, desenhada para alta disponibilidade e throughput.

Comparação por critério

Controle operacional e acesso superuser

• PostgreSQL autogerenciado: acesso total a superuser, controle irrestrito de parâmetros, versão e extensões.

• Supabase (plano gerenciado/cloud): acesso restrito — não há papel superuser completo, e a plataforma limita quais extensões podem ser habilitadas. Isso é intencional: é o preço da automação de backup, HA e patching. O número de extensões liberadas atualmente no Supabase Cloud é algo em torno de 60-70 extensões pré-aprovadas em fontes de terceiros.

• Aurora: mesma lógica de restrição de superuser que qualquer RDS/Aurora — a AWS bloqueia acesso a nível de SO e restringe extensões (via rds.allowed_extensions) para poder garantir os SLAs de backup e failover.

  
  

Extensões e customização

• Autogerenciado: qualquer extensão do ecossistema PostgreSQL, sem aprovação prévia — inclusive extensões de terceiros ou compiladas localmente.

• Supabase: lista de extensões pré-aprovadas pela plataforma; algumas extensões usadas pelo próprio produto (ex.: pg_net para webhooks, pgsodium/vault para segredos) fazem parte do pacote da plataforma gerenciada e não necessariamente estão disponíveis (ou fazem sentido) fora dela.

• Aurora: lista de extensões suportadas publicada pela AWS por versão de engine — mais restrita que autogerenciado, tipicamente mais ampla que a lista da Supabase Cloud, mas isso muda por versão.

  
  

Arquitetura de alta disponibilidade e storage

• Autogerenciado: HA é responsabilidade sua — replicação streaming, Patroni/repmgr, failover manual ou orquestrado por você.

• Supabase: réplicas de leitura e HA disponíveis conforme o plano; a arquitetura de storage por trás é Postgres convencional (não é um storage distribuído proprietário como o da Aurora).

• Aurora: arquitetura própria que desacopla compute de storage. O storage é replicado 6 vezes entre 3 Availability Zones, com tolerância a perda de até 2 cópias sem impacto em escrita e até 3 cópias sem impacto em leitura. Suporta até 15 réplicas de leitura lendo do mesmo storage compartilhado, com lag de replicação tipicamente sub-10ms — isso é estruturalmente diferente de replicação streaming tradicional, porque as réplicas não copiam dados, apenas leem do storage compartilhado.

  
  

Escalabilidade

• Autogerenciado: escala vertical manual (redimensionar a instância) ou horizontal via sharding/particionamento — tudo desenhado e operado por você.

• Supabase: upgrade de compute add-on (troca de instância) feito pela plataforma; não há um modelo serverless de banco propriamente dito no sentido de autoscaling contínuo de compute por carga.

• Aurora: além do modelo provisionado tradicional, existe o Aurora Serverless v2, que permite definir um range mínimo/máximo de ACUs (Aurora Capacity Units) e escala compute e memória automaticamente em frações de segundo conforme a carga real, mantendo paridade de recursos com as instâncias provisionadas.

  
  

Connection pooling e limite de conexões

• Autogerenciado: você escolhe e opera o pooler (PgBouncer, Pgpool, etc.) e define os limites.

• Supabase: pooling embutido via Supavisor (sucessor do PgBouncer na plataforma), com limites de conexão direta e de conexão via pool que variam por tier de compute.

• Aurora: sem pooler nativo embutido no motor — é comum combinar com RDS Proxy (serviço separado da AWS) ou um pooler operado por você (PgBouncer) na camada de aplicação.

  
  

Modelo de custo

• Autogerenciado: custo de infraestrutura (VM/servidor) mais o custo de tempo de operação — backup, patching, monitoramento, tuning — que não aparece na fatura, mas existe.

• Supabase: assinatura mensal fixa por plano (inclui uma cota de compute credit) mais cobrança de excedente por uso — armazenamento, egress, MAUs de Auth, invocações de Edge Functions, entre outros itens, dependendo do plano. Deve-se avaliar os valores exatos de mensalidade e cotas por plano na página oficial de pricing da Supabase, pois esses valores mudam com frequência.

• Aurora: cobrança por instância (on-demand ou reservada), por armazenamento e por I/O — com duas opções de configuração, Aurora Standard (cobra por milhão de requisições de I/O) e Aurora I/O-Optimized (sem cobrança de I/O, mas com tarifa de armazenamento mais alta, indicada quando o custo de I/O já é uma fatia grande da fatura). Também deve-se verificar os valores exatos de $/GB e $/milhão de I/O na página oficial de pricing da AWS para a região usada, pois variam por região e mudam com frequência.

  
  

Portabilidade e vendor lock-in

• Autogerenciado: portabilidade máxima — é PostgreSQL puro, migra para qualquer lugar que rode Postgres.

• Supabase: o banco em si é Postgres padrão (dump/restore funcionam normalmente), mas a camada de produto (Auth, Storage, Realtime, Edge Functions, RLS desenhado em torno de auth.uid()) cria dependência arquitetural da plataforma — migrar o banco é simples, migrar a aplicação inteira não é.

• Aurora: compatível com o protocolo e a maior parte do comportamento do PostgreSQL, o que facilita migração de dados, mas alguns comportamentos internos (replicação, extensões proprietárias de storage) são específicos da Aurora e não existem em Postgres padrão.

  
  

Funcionalidades além do banco

• Autogerenciado e Aurora: nenhum dos dois entrega Auth, Storage ou APIs REST/GraphQL automáticas — isso fica por conta da sua stack de aplicação.

• Supabase: entrega essa camada pronta, o que reduz tempo de desenvolvimento no início do projeto, mas significa que parte da lógica de autorização (RLS + políticas) passa a viver dentro do banco como mecanismo de segurança de aplicação, não só como controle de acesso a dados — uma escolha de design que precisa ser bem entendida por quem administra o banco depois.

  
  

Quando cada opção faz mais sentido

PostgreSQL autogerenciado compensa quando a equipe já tem DBA/SRE dedicado, exigências de compliance que impõem controle total do ambiente, ou uso de extensões/configurações que nenhuma plataforma gerenciada libera.

Supabase compensa quando o projeto se beneficia da camada de produto (Auth, Realtime, Storage, APIs automáticas) e o time quer reduzir tempo de desenvolvimento de backend — o trade-off aceito é menos controle operacional sobre o Postgres em si.

Aurora compensa quando a prioridade é um motor relacional PostgreSQL-compatível com alta disponibilidade e throughput como características centrais de infraestrutura, sem a camada de produto — tipicamente em ambientes que já estão no ecossistema AWS e precisam de HA robusta com operação delegada, mas mantendo o desenho de aplicação (Auth, APIs) em outra camada.

Conclusão

Não existe "melhor opção" fora de contexto — existe a opção cujo trade-off de controle, custo operacional e superfície de responsabilidade combina com o estágio e a equipe do projeto. Quem decide baseado só em preço de tabela costuma redescobrir, alguns meses depois, o custo real de superuser restrito, limite de extensão ou ausência de pooler nativo — e isso vale tanto para Supabase quanto para Aurora. Aqui na Siltech tratamos de projetos envolvendo ambos estes ambientes, e, como regra, ajudamos o cliente a avaliar o que ele ganha ou perde de acordo com o escopo do projeto do mesmo. Se tiver dúvidas, ou precisar de apoio para uma decisão deste nível (ou para migrar de uma arquitetura que não esteja atendendo), ficamos à disposição: silverio@siltechconsult.com.br^.