Supabase ou PostgreSQL puro no seu próprio servidor

A configuração Docker auto-hospedada do Supabase, versão v0.8.3 de 16 de outubro de 2026, inicia 11 contêineres. Um deles é o PostgreSQL 17. Os outros dez são um gateway, login, uma API REST, armazenamento de arquivos, redimensionamento de imagens, atualizações em tempo real, funções de servidor, um pooler de conexões, uma API de administração do banco de dados e o painel Studio. Em um servidor x86, as 11 imagens somam cerca de 2,15 GB de download, segundo a nossa soma dos tamanhos x86 informados no Docker Hub para as tags de imagem do arquivo compose. A imagem oficial do PostgreSQL 17 tem cerca de 161 MB.

A documentação da API do Supabase descreve duas formas de usá-lo. Você pode chamar as APIs dele assim: directly from the browser (two-tier architecture), or as a complement to your own API server (three-tier architecture). Se um navegador ou app de celular se comunica com o seu banco de dados, esses dez serviços são o backend que você teria que escrever. Se há um servidor seu no meio do caminho, o PostgreSQL é a parte que o seu app usa.

O que o Supabase adiciona ao PostgreSQL

Para cada tarefa abaixo, a coluna do meio indica o serviço do Supabase que a executa, com base na página de arquitetura do Supabase e no README auto-hospedado dele na v0.8.3.

Nossa escolha para um caso comum: um app Next.js, React ou mobile que ainda não tem código de servidor é o que mais aproveita o Supabase. Sem ele, tudo isso é código que você escreveria antes do lançamento. Uma equipe que já tem um backend em Rails, Django ou Express ganha pouco com os dez serviços extras.

A DreamHost vende os dois como servidores com o software já instalado, a Hospedagem VPS Supabase e a Hospedagem VPS PostgreSQL, nos mesmos planos Stack e pelos mesmos preços. Se você usa o Supabase Cloud hoje e quer saber se um servidor sairia mais barato, comece por quanto o Supabase Cloud custa conforme você cresce. Se está comparando um serviço de PostgreSQL gerenciado com o PostgreSQL puro em um servidor, leia quanto custa o Postgres gerenciado em comparação com um servidor.

O que funcionou logo no primeiro dia

Testamos cada tarefa no Supabase logo após a instalação, sem nenhum código nosso além de scripts de teste, e as sete funcionaram.

• Fazer login de um usuário e obter um token. Criamos o usuário pela API de administração, já que a configuração padrão não tem servidor de e-mail para os e-mails de confirmação.
• Ler e gravar uma tabela via HTTP sob uma política de segurança em nível de linha. O usuário logado viu a sua 1 linha, e uma requisição sem usuário logado recebeu 0 linhas.
• Enviar um arquivo e baixar os mesmos bytes. Usamos um bucket privado, e o download bateu byte a byte.
• Redimensionar uma imagem. O serviço imgproxy transformou um PNG de 800x600 em um de 200 pixels de largura.
• Chamar uma função de servidor. A função hello incluída respondeu.
• Receber um evento quando uma linha é adicionada. Um cliente supabase-js recebeu a nova linha 283 ms após a inserção.
• Abrir um painel web. O Studio pediu o login primeiro.

No PostgreSQL 17 puro, executamos as duas tarefas que o banco de dados faz sozinho. A mesma política de segurança em nível de linha funcionou em SQL, e LISTEN e NOTIFY levaram um evento entre duas sessões SQL. O resto precisa de software além do banco de dados: uma API HTTP, login, armazenamento de arquivos, funções de servidor, uma conexão do navegador para atualizações em tempo real e um painel.

O Realtime nos pegou de surpresa na primeira execução: o cliente supabase-js informou que tinha se inscrito após 35 ms, e a linha que inserimos logo em seguida nunca chegou. Na nova execução, registramos os eventos de sistema do canal: o cliente disse subscribed aos 32 ms, e a mensagem Subscribed to PostgreSQL do próprio Realtime chegou cerca de 2,4 segundos depois. Se o seu app grava uma linha logo após se inscrever, escute o evento system do canal e espere essa mensagem antes de inserir.

O que cada um exige do seu servidor

O Supabase publica os requisitos da sua stack. O PostgreSQL não, então nossas medições preenchem essa lacuna. Na tabela, Supabase significa a configuração auto-hospedada v0.8.3 e PostgreSQL significa o PostgreSQL 17 puro.

As linhas de memória em repouso até extensões são medições nossas, de 19 de outubro (VM de 8 GB) e 20 de outubro de 2026 (VM de 4 GB), descritas em como medimos. Os tempos consideram as imagens já baixadas. As contagens vêm do arquivo compose na tag self-hosted/v0.8.3 do Supabase, os tamanhos de download vêm dos dados de tags do Docker Hub e os requisitos, da documentação de cada fabricante, tudo consultado em 16 de outubro de 2026.

Logs & Analytics vêm desativados na configuração padrão do Supabase para reduzir o consumo de memória, e você os ativa com um arquivo de override que adiciona Logflare e Vector e aumenta o que a stack exige.

O Stack 4 atende ao mínimo do Supabase. O Stack 8 adiciona a RAM e o disco recomendados, mas mantém 2 vCPU. O Stack 16 é o menor plano que atende a todos os números recomendados pelo Supabase, com 4 vCPU, 16 GB de RAM e 250 GB de armazenamento NVMe, segundo a página de VPS para Supabase, então é a nossa escolha para produção, e o Stack 8 serve para um app pequeno ou uma cópia de staging.

Nosso teste com 4 GB mostra que a stack padrão cabe no Stack 4 em repouso. Os 11 contêineres continuaram rodando sem reiniciar, e a memória deles se estabilizou em pouco mais de um terço dos 3.904 MiB da VM. As imagens ocuparam cerca de 9,7 GB de disco, bem dentro dos 75 GB do Stack 4.

A mesma stack usou cerca de 50% mais memória na VM de 4 GB do que na de 8 GB. Studio, Realtime e o pooler subiram de 16% a 22%, e cinco serviços pequenos aumentaram de duas a sete vezes, como o imgproxy, que foi de cerca de 13 MiB para 94 MiB. Executamos cada teste uma única vez e não conseguimos explicar a diferença, então planejaríamos de 1 a 1,5 GB para o Supabase em repouso e dimensionaríamos o tráfego do seu app em cima disso.

Para o PostgreSQL sozinho, colocaríamos um banco de dados de produção no Stack 8, o plano que a página de VPS para PostgreSQL descreve como Para apps rodando em produção. O Stack 4, descrito como Para apps leves e projetos individuais, basta para começar. A página diz que migrar do Stack 4 para o Stack 32 é simples, e o seu ambiente vai junto. Para dimensionar o servidor para qualquer outra coisa que você vá rodar nele, veja de qual plano VPS você precisa.

O que o PostgreSQL puro deixa por sua conta

O seu backend cuida dessas tarefas, e o Rails e o Django já trazem boa parte disso. O Rails vem com um gerador de autenticação, o Active Storage cuida dos envios e das variantes de imagem, e o Action Cable oferece WebSockets ao navegador. O Django tem um sistema de autenticação de usuários nativo, e o Channels adiciona WebSockets. Um app Express adiciona tudo isso como bibliotecas, por exemplo o Socket.IO para uma conexão bidirecional em tempo real entre o navegador e o seu servidor.

O próprio PostgreSQL cobre parte da lista. As políticas de segurança de linha dele limitam, para cada usuário, quais linhas uma consulta retorna ou altera, e as regras de acesso do Supabase são essas mesmas políticas. O LISTEN e o NOTIFY enviam um evento a cada sessão do banco de dados que estiver escutando, então um worker no seu backend pode reagir a novas linhas. Um navegador não abre sessões no banco de dados, então as atualizações em tempo real no navegador passam por um servidor WebSocket seu, como o Action Cable, o Channels ou o Socket.IO. Extensões como pgvector e PostGIS podem ser instaladas no nosso servidor PostgreSQL com acesso root completo.

Se a API automática é a peça de que você sentiria falta, você pode rodar o PostgREST sozinho. Ele é o servidor web por trás da API REST do Supabase, e o README dele diz que ele serves a fully RESTful API from any existing PostgreSQL database.

O dia a dia com o Supabase auto-hospedado

A página de auto-hospedagem do Supabase lista o que você assume ao rodá-lo: manutenção do servidor, manter o sistema operacional e os serviços atualizados, manutenção do Postgres, alta disponibilidade, e backups e recuperação.

• HTTPS. A própria configuração Docker do Supabase responde em HTTP simples, o que é aceitável em uma máquina de teste. Para uso em produção, o guia de proxy do Supabase coloca Caddy ou Nginx com Let’s Encrypt na frente do gateway.
• E-mail. As configurações Docker padrão do Supabase ativam o cadastro por e-mail com confirmação e apontam o envio de e-mails para um contêiner que só existe no arquivo de desenvolvimento do Supabase. Adicione o seu próprio servidor SMTP antes que usuários reais se cadastrem, ou os e-mails de confirmação e redefinição de senha não serão enviados.
• Atualizações. O guia Docker do Supabase diz que ele publica um snapshot estável cerca de uma vez por mês. O script de atualização dele mescla as configurações da nova versão com as suas. Depois, você baixa as novas imagens e recria os contêineres. Faça backup antes de executá-lo.
• Projetos. Uma instalação roda um projeto. O Studio auto-hospedado não comporta várias organizações ou projetos, então um segundo app precisa da sua própria instalação.

O passo a passo de auto-hospedagem traz as etapas de configuração, e o guia de Docker do Supabase é a referência para cada configuração.

Como medimos

A DreamHost rodou as duas stacks em 19 de outubro de 2026, em uma VM de teste local com 2 vCPUs e 7.922 MiB de memória: Ubuntu 24.04.4 em arm64, sob o Colima em um Mac com Apple silicon. Nossos planos rodam em processadores AMD EPYC x86, então este não era um servidor da DreamHost. Como o tamanho das imagens varia conforme o processador, a tabela também informa o download para x86.

O Supabase rodou a partir da pasta Docker da v0.8.3, do jeito que foi publicada, com segredos gerados pelos próprios scripts de chaves dele. O PostgreSQL rodou a partir do arquivo compose de exemplo do Docker Hub, fixado em postgres:17.11, sem o serviço Adminer. Cada valor de memória é a mediana de 12 leituras do docker stats, uma a cada 5 segundos, começando 10 minutos após a inicialização. As imagens foram baixadas antes de cronometrarmos as inicializações.

Em 20 de outubro, rodamos o Supabase de novo em uma segunda VM com o tamanho do Stack 4: 2 vCPUs, 3.904 MiB de memória e sem swap, com as mesmas versões do Ubuntu e do Docker. Usamos uma cópia nova da mesma pasta v0.8.3, novos segredos e as mesmas 12 leituras após 10 minutos. Um pequeno app de teste sem relação com o Supabase, com cerca de 180 MiB, também estava rodando nessa VM. Ele não entra em nenhum dos números do Supabase que citamos.

Rodamos cada configuração uma única vez, então não há variação a relatar. Os testes cobrem uma stack ociosa e o que funciona logo após a instalação. Eles não cobrem um app sob carga nem uma semana de funcionamento, e não testamos com Logs & Analytics ativado.

Perguntas frequentes sobre Supabase ou PostgreSQL puro