Quanto o Supabase vai custar conforme você cresce, e quando um servidor sai mais barato?

Enquanto seu projeto couber em uma instância Micro e ficar dentro das cotas incluídas, o crédito de computação faz com que a taxa do plano seja a fatura inteira. Um projeto de staging, uma instância maior e o tráfego além das cotas incluídas acrescentam, cada um, sua própria linha. No nosso maior exemplo, a taxa por usuário ativo mensal foi a maior linha individual, porque ela continua subindo depois dos 100.000 usuários incluídos no Pro.

O que você paga no Supabase Pro

Além das cotas incluídas, usuários, tráfego de saída, disco, arquivos e chamadas de funções são cobrados cada um pelo seu próprio preço, segundo a página de preços do Supabase.

A documentação de cobrança do Supabase acrescenta quatro regras que aumentam a fatura quando seu app cresce:

• O crédito de computação só paga computação. Você recebe US$ 10 por mês, segundo a documentação de computação do Supabase. Isso basta para uma instância Micro, e nada dele vai para tráfego de saída, usuários ou disco.
• Cada projeto tem sua própria instância de computação, então uma cópia de staging da produção acrescenta uma segunda linha de computação que o único crédito não cobre.
• O disco é cobrado pelo tamanho que o Supabase atribui a você. A documentação sobre tamanho do banco de dados diz que o disco cresce 50% cada vez que o banco atinge 90% dele, então um banco de 20 GB acaba em um disco de 27 GB. Você paga pelos 27, menos os 8 GB incluídos no Pro.
• O Pro inclui 8 GB de disco por projeto, e cada GB acima disso custa US$ 0,125 por mês.

Para calcular o seu mês, abra a página de uso e some estes itens, nesta ordem:

1. Comece com US$ 25 do plano.
2. Some a computação de cada projeto pelos preços mensais arredondados do Supabase (US$ 10 Micro, US$ 15 Small, US$ 60 Medium, US$ 110 Large) e subtraia o crédito de US$ 10 uma única vez. A computação é cobrada por hora. Um projeto que rodou só parte do mês custa menos.
3. Some US$ 0,00325 por usuário ativo mensal além de 100.000. Isso dá US$ 32,50 a cada 10.000.
4. Some US$ 0,09 por GB de tráfego de saída além de 250 GB, mais US$ 0,03 por GB de tráfego de saída em cache além dos seus próprios 250 GB.
5. Some US$ 0,125 por GB de disco além de 8 GB em cada projeto, usando o tamanho de disco mostrado para o projeto.
6. Some US$ 0,0213 por GB de arquivos além de 100 GB e US$ 2 por milhão de chamadas de Edge Functions além de 2 milhões.
7. Some US$ 2,50 por milhão de mensagens Realtime além de 5 milhões e US$ 10 por 1.000 conexões de pico além de 500.
8. Some os complementos que você ativou, como US$ 100 por mês por 7 dias de recuperação para um ponto no tempo.

Por que os projetos saem do plano Free

O Free cobre até 2 projetos ativos, cada um com 50.000 usuários ativos mensais, banco de dados de 500 MB, 5 GB de tráfego de saída e 1 GB de armazenamento de arquivos, segundo a página de preços do Supabase. Se seu projeto adormeceu depois de uma semana parada, você esbarrou em um dos limites do Free: um projeto Free é pausado após uma semana sem atividade, e o banco de dados passa a ser somente leitura quando ultrapassa 500 MB. Também não há backup automático, por isso o Supabase orienta quem usa o Free a exportar os próprios dados com a CLI e guardar cópias em outro lugar.

Projetos pagos não são pausados por inatividade, e o Pro mantém backups diários por sete dias.

Como o limite de gastos funciona em um app em crescimento

Digamos que seu tráfego de saída passe de 250 GB no dia 20 do mês. O limite de gastos vem ativado por padrão no Pro, então do dia 20 até o próximo ciclo de cobrança o tráfego de saída acima de 250 GB fica bloqueado. O mesmo vale para cada item coberto que passar da cota, segundo a documentação do Supabase sobre como funciona o limite de gastos.

Com o limite ativado, o disco do Pro também para de crescer em 8 GB. O limite de gastos não permite definir orçamento ou alerta para um item específico, e você não pode ativá-lo para algumas linhas e desativá-lo para outras.

Três tamanhos de app, com preço linha por linha

Cada exemplo usa o Supabase Pro no plano mensal, em dólares americanos antes de impostos, com os preços mensais arredondados de computação do Supabase. O uso é uma suposição nossa, então troque pelos seus números:

• O tráfego de saída sem cache cresce cerca de 10 MB por usuário por mês, nosso número redondo para um app leve; sua página de uso mostra o seu. O app mais movimentado também serve 500 GB pelo cache do Supabase.
• Os tamanhos de disco são nossa estimativa com base na regra de crescimento do Supabase: 8 GB no início e mais 50% cada vez que o banco atinge 90% do disco. O Supabase pode arredondar.
• Os dois apps maiores rodam um projeto de staging com computação Micro. O projeto paralelo, não.
• A recuperação para um ponto no tempo (PITR) é cobrada à parte, por US$ 100 por mês para sete dias de histórico, e exige pelo menos computação Small.

Um projeto paralelo que acabou de sair do Free

Digamos que você tenha 5.000 usuários, um banco de 2 GB, 50 GB de tráfego de saída e 5 GB de arquivos enviados, o que deixa todos os medidores bem dentro das cotas do Pro, e o crédito de computação anula a instância Micro.

Você não precisa desativar o limite de gastos. A recuperação para um ponto no tempo aumenta a fatura, porque tem taxa própria e tira você da instância Micro que o crédito paga.

Um SaaS em crescimento com 40.000 usuários

Este exemplo inclui um projeto de staging, para que ninguém teste uma mudança de esquema direto na produção. Ele tem 40.000 usuários mensais, um banco de 20 GB, 400 GB de tráfego de saída, 60 GB de arquivos e um milhão de chamadas de Edge Functions.

Do que surgiu de novo em relação ao projeto paralelo, cerca de metade vem do staging e de uma instância de produção maior, e o resto do excedente de disco e de tráfego de saída. É também por causa desse excedente que esta é a primeira fatura que obriga a desativar o limite de gastos.

Um app mais movimentado com 200.000 usuários

Com 200.000 usuários, você passa da cota do Pro em quase todas as linhas que crescem com o número de pessoas. Este exemplo considera 2 TB de tráfego de saída comum mais 500 GB servidos pelo cache do Supabase, que tem cota própria e preço menor. Consideramos que a produção roda em computação Large, com 2 vCPUs dedicadas e 8 GB de RAM.

Uma instância menor quase não reduziria essa fatura, já que a computação é menos de um quinto do total depois do crédito. A taxa por usuário continua subindo a cada novo usuário ativo além de 100.000.

Supabase ao lado de um servidor

A tabela coloca as três faturas do Supabase ao lado de um servidor autogerenciado com o Supabase pré-instalado. O servidor não tem taxa por usuário, e a largura de banda é ilimitada em todos os planos (sujeita à política de uso justo), então não há uma linha de transferência de dados para acompanhar. O preço muda quando o valor promocional termina, após 3 meses, ou se o seu projeto ficar grande demais para o plano e você migrar para um maior.

A coluna do servidor mostra o preço promocional e o preço de renovação. Usamos o preço de renovação em todos os pontos de virada deste guia e, mesmo antes de contar qualquer hora do seu tempo, o SaaS em crescimento já paga mais do que isso ao Supabase. O Stack 16 é o plano da tabela porque é o menor dos nossos planos que atende a todos os requisitos de auto-hospedagem recomendados pelo Supabase. O Stack 8 tem a RAM e o disco, mas suas 2 vCPUs só alcançam o mínimo do Supabase, enquanto as 4 vCPUs do Stack 16 correspondem aos 4 núcleos que o Supabase recomenda:

O Supabase considera o mínimo adequado para desenvolvimento e para apps de produção pequenos e médios, e é aí que o Stack 8 se encaixa.

O que o stack ocupa antes de seus usuários chegarem

A comparação de preços só vale se a stack couber no plano, então rodamos a configuração Docker auto-hospedada do próprio Supabase, versão v0.8.3, em duas máquinas de teste e medimos a memória depois que ela se estabilizou. As duas tinham 2 vCPUs. Uma tinha 8 GB de memória e a outra 4 GB, o tamanho do mínimo do Supabase e do Stack 4.

As imagens desses 11 contêineres ocuparam cerca de 9,7 GB de disco. A memória da própria stack é uma pequena parte dos 16 GB do Stack 16, então quase tudo fica livre para o cache do seu banco e para seus usuários. O teste com 4 GB mostra que ela também inicia e fica ociosa em uma máquina de teste do tamanho do nosso menor plano. Nenhum dos testes teve tráfego, então nenhum diz quantos usuários um plano aguenta. A escolha do plano continua se baseando nos 4 núcleos recomendados pelo Supabase, e o teste de carga nas etapas mais abaixo é como você confirma isso para o seu app.

No Cloud, a instância de computação Large do app mais movimentado tem 8 GB de RAM. No seu servidor, o Postgres divide os 16 GB com Auth, Storage, Realtime e o resto da stack.

O que o preço do servidor deixa de fora

O preço do plano compra um servidor com a stack do Supabase rodando nele, e a página de auto-hospedagem do Supabase lista o que não vem junto. Branching, backups gerenciados, PITR, métricas avançadas, buckets de analytics e de vetores, ETL e a API de gerenciamento são exclusivos do Cloud.

A tabela de custos também deixa de fora e-mail e armazenamento de backups. O guia de auto-hospedagem com Docker do Supabase diz que você vai precisar de um servidor SMTP pronto para produção para enviar os e-mails de cadastro e de senha, então conte com um serviço de e-mail transacional. Seus backups devem ficar em outro lugar que não o próprio servidor, como um armazenamento compatível com S3. No lado do servidor, você paga pelos dois além do plano. Nós não calculamos esses custos, porque eles dependem do seu volume de e-mails, de quanto você armazena e por quanto tempo guarda os backups.

O banco de dados de 60 GB e os 120 GB de arquivos do app mais movimentado cabem em 250 GB de disco, mas com menos folga do que parece, porque o sistema operacional, as imagens Docker (cerca de 9,7 GB as do Supabase no nosso teste), os logs e uma restauração em andamento também ocupam espaço. Guarde os backups em outro lugar e configure um alerta de espaço livre em disco ao montar o servidor.

O staging também fica de fora do lado do servidor, porque o Supabase auto-hospedado roda um projeto por stack, então uma cópia de staging exige uma segunda stack, no mesmo servidor ou em outro. Nós não testamos duas stacks em um só servidor. Se você tirar o staging do lado do Cloud para igualar a comparação, a conta do SaaS cai US$ 10, para US$ 45,88, e a do app mais movimentado vai para US$ 627,82. Mesmo sem staging, o SaaS continua abaixo do ponto de virada que você verá na próxima seção, e o app mais movimentado continua bem acima dele.

Onde o servidor vence quando seu tempo entra na conta

A manutenção de rotina do seu próprio servidor inclui atualizações do sistema operacional, novas imagens Docker, uma olhada nos logs e a confirmação de que o backup da noite anterior rodou, e tudo isso soma de uma a duas horas por mês, pela estimativa do nosso guia sobre como auto-hospedar o Supabase e o que você perde com isso. A mediana salarial de 2025 nos EUA para desenvolvedores de software, analistas de QA e testadores é de US$ 64,44 por hora, segundo o Bureau of Labor Statistics, o que coloca essas horas entre US$ 64,44 e US$ 128,88 por mês.

Some essas horas ao preço de renovação do servidor na tabela acima. Veja a partir de qual conta do Supabase o servidor com a manutenção passa a custar menos. Os meses de exemplo são nossos palpites sobre quando cada quantidade de manutenção acontece:

A conta do app mais movimentado passa até da linha de oito horas. Cada hora desloca a linha pelo valor da sua hora, então, se a sua vale US$ 100, a linha de uma hora vai para cerca de US$ 135. Some também ao lado do servidor o armazenamento de backups, um serviço de e-mail e uma migração única.

Com PITR, a conta de US$ 155,88 do SaaS em crescimento fica dentro da faixa de uma a duas horas, de cerca de US$ 100 a US$ 164, mas um servidor auto-hospedado não inclui recuperação point-in-time gerenciada. Você teria que montar e operar essa recuperação por conta própria. Você também abriria mão dos sete dias de backups diários que o Cloud Pro guarda para você. Se a recuperação é o motivo de você pagar pelo PITR, fique, ou reserve tempo para montar e testar seus próprios backups antes de migrar. O app mais movimentado paga ao Supabase várias centenas de dólares por mês a mais do que o servidor e duas horas do seu tempo somados, mas essa economia só vale se um único servidor aguentar sua carga, então faça um teste de carga antes de contar com ela.

Se o seu app só usa o banco de dados, o guia sobre quanto custa só o Postgres gerenciado em comparação com um servidor calcula esse caso. Se você ainda está decidindo se precisa mesmo da stack completa do Supabase, nosso guia sobre rodar Supabase ou PostgreSQL puro compara os dois em um servidor.

Antes de migrar a produção

Na discussão do Supabase no GitHub sobre auto-hospedagem, um desenvolvedor descreveu a preocupação assim:

Faça estes passos em ordem, em uma cópia dos seus dados, enquanto o projeto no Cloud ainda atende os usuários:

1. Restaure um backup recente no servidor

   Faça backup do banco de dados com a Supabase CLI e restaure-o no servidor, seguindo os passos de dump do guia de backup e restauração do Supabase. Cronometre a restauração, porque esse é o tempo de recuperação do banco de dados se o servidor falhar, e ensaie também uma reconstrução completa uma vez.

2. Migre as partes que ficam fora do banco de dados

   Usuários do Auth, arquivos do Storage e Edge Functions têm cada um seu próprio caminho de migração, então confira cada um. Depois, cadastre um usuário de teste e confirme que o e-mail chega pelo seu servidor SMTP.

3. Teste a carga como em produção

   Rode suas consultas mais pesadas e abra tantas conexões Realtime quanto o pico mostrado na sua página de uso. Acompanhe a memória enquanto faz isso.

4. Configure backups que saiam do servidor

   Envie backups noturnos para fora do servidor, por exemplo para um armazenamento compatível com S3. Depois, restaure um deles.

5. Planeje a migração e o caminho de volta

   Escolha um horário tranquilo. Mantenha o projeto no Cloud até o servidor completar um ciclo de cobrança inteiro e anote como você voltaria atrás.

Ficar ou migrar

Conte suas próprias horas antes de decidir. Cronometre a restauração e o teste de carga acima para ver quanto a migração custa para você e, depois, registre sua manutenção no primeiro mês para substituir nossa estimativa de uma a duas horas no ponto de virada.

Como calculamos os preços e testamos

As contas do Cloud são cálculos da DreamHost com base na tabela de preços e na documentação de cobrança do Supabase, consultadas em 28 de setembro de 2026. Consultamos a tabela de preços de novo em 21 de outubro, e nenhum valor das tabelas mudou. O uso em cada exemplo é uma suposição nossa, e não abrimos uma conta no Supabase Cloud para testá-lo.

Os números do servidor foram medidos pela DreamHost em uma VM de teste (arm64), não em um servidor da DreamHost. Os testes foram feitos para o nosso guia sobre Supabase ou PostgreSQL puro, e esta página os reaproveita. Eles rodaram em um Mac com Colima, Ubuntu 24.04 e 2 vCPU: 8 GB de memória em 19 de outubro de 2026 e 4 GB em 20 de outubro. A pasta Docker v0.8.3 do Supabase rodou do jeito que foi publicada. Cada número de memória é a mediana de 12 leituras de docker stats, com 5 segundos de intervalo, feitas 10 minutos após a inicialização. Nossos planos rodam em processadores x86 AMD EPYC, então os tamanhos das imagens no seu servidor serão diferentes.

O que não testamos: qualquer tráfego ou carga, uma semana de funcionamento, 4 vCPU, o complemento Logs & Analytics, uma restauração e duas stacks do Supabase em um só servidor. Cada configuração rodou uma vez.

Perguntas frequentes sobre os preços do Supabase