O Supabase é um backend muito bom: Postgres de verdade, um sistema de autenticação, storage, realtime, edge functions e uma API gerada a partir do seu schema. Ele entrega poder e espera que você saiba o que fazer com ele: o schema, as políticas de row level security e todo o frontend são seus para escrever. O 54 vai para o outro lado: você descreve o que o site faz e os dados aparecem já conectados.
| Supabase | 54 | |
|---|---|---|
| O que ele te dá | Postgres, Auth, Storage, Realtime, Edge Functions e uma API gerada | Um site publicado com seus dados, seu formulário, seu admin e seus logins já conectados |
| O frontend | Você constrói e hospeda em outro lugar | Construído e hospedado aqui, a partir da mesma descrição |
| Schema e permissões | Você desenha tabelas e escreve políticas de Row Level Security | As coleções são criadas pelo prompt; o dono vê o admin, o público vê o formulário |
| SQL | Postgres completo — uma vantagem real se você quiser | Você nunca escreve. Essa é a troca: menos poder bruto, curva de aprendizado zero |
| Logins | Completos: e-mail, senha, provedores OAuth, magic links | Login por código no e-mail para quem usa o seu site |
| Hospedagem e domínio | Não inclusos — isso é outro provedor | Inclusos, com SSL e seu próprio domínio |
| Para quem é | Desenvolvedores que querem um banco de dados real e controle total | Quem quer a coisa funcionando, e desenvolvedores construindo algo pequeno rápido |
Escrito a partir da documentação pública de cada produto. Produtos mudam: confira o deles antes de decidir. Pelo mesmo motivo, aqui não há preços da concorrência.
Para "meu site precisa guardar dados e ter logins", sim. Para "preciso de Postgres, migrações e row level security sob meu controle", o Supabase é a resposta certa e é melhor.
Não. Você nunca vê. Você descreve o que o site guarda e as coleções são criadas, junto com o formulário que escreve nelas e a tela onde você lê.
Sim. Ficam visíveis no admin e podem ser baixados. Dados que você não consegue tirar não são realmente seus.
Tudo que vem de ter Postgres de verdade: consultas complexas, joins, índices, migrações, triggers, assinaturas realtime e row level security fina. O 54 deliberadamente não expõe essa superfície.
Constrói e hospeda o site, publica no seu domínio e depois faz trabalho de SEO e growth. O Supabase é o backend; o resto é com você.
Quem usa o seu site recebe um código por e-mail e entra. Nada para lembrar e nada sensível para você guardar.
Sim. Cada site tem suas próprias coleções e só o dono chega ao admin.
Você pode chamar qualquer API HTTP a partir do seu site, inclusive a do Supabase. A configuração pública vai nas variáveis do site; uma service key nunca vai numa página, em plataforma nenhuma.
Postgres sob seu controle escala mais longe e em mais direções. Se você já está pensando em réplicas de leitura e pooling de conexões, essa pergunta já se respondeu sozinha.
Sim. Baixe os arquivos e os dados e refaça o backend quando o projeto realmente precisar. A maioria descobre que nunca precisou.