Supabase em produção: os 3 riscos que me fazem não usar

A carteirada primeiro: eu nunca usei, e sei por quê

"Josimar, você já usou Supabase?" Aí vem um ponto importante: não, nunca usei. Pra mim não faz o menor sentido. Mas eu sei do que se trata, sei tecnicamente por que eu não usei e sei como funciona. É sobre isso a conversa: banco de dados remoto via HTTP, onde isso é um tiro no pé e onde não é.

Eu dou a minha carteirada pra você saber de onde vem a opinião. Eu sou engenheiro de infraestrutura (não tenho CREA, antes que alguém me xingue de novo por isso). Eu trabalho gerenciando CDN e infraestrutura pesada no Brasil e nos Estados Unidos. Sou CEO, diretor, dono, mão na massa: cuido de equipe de dev, marketing, mobile, suporte e venda. Uma empresa real. E sou vibe coder também. Não é papagaio de pirata repetindo o que leu na internet.

E já aviso: o Supabase não é o pior do mundo nem o melhor do mundo. Nem um nem outro. É uma empresa grande, e eu não estou tirando o mérito dos caras: eles pegaram a onda do low code e criaram um mercado, o backend as a service, que é a abstração completa da infraestrutura e do backend. Foi inteligente da parte deles. O problema está em quem usa sem entender de fornecedor, de latência e de banco de dados na hora de subir pra produção.

Pra que eu usaria: prototipar e testar rápido

Eu usaria pra prototipar e testar alguma coisa rápida. A facilidade que ele traz com a abstração de backend e de login é muito bacana quando você quer validar uma ideia. Você pega o plano gratuito e faz o seu protótipo. Até aí, tudo certo.

E eu entendo por que isso seduz. Infraestrutura é o que deixa o dev surtar, e já me deixou. Infraestrutura não é pra qualquer um: não é qualquer pessoa nem qualquer equipe que consegue botar um ambiente pra rodar em produção de forma séria, em alta disponibilidade, e ainda geodistribuído, sem depender de um local só. Caiu, como é que faz pra voltar?

Pega o exemplo de quem resolve subir o próprio banco. Você sobe um Postgres, ele escuta na porta nativa dele, num IP. Uma aplicação de front-end não vai conectar ali. Ou você vai deixar IP e porta de banco abertos na internet? Não pode. Então precisa de um proxy na frente pra receber a conexão, precisa de validação (você não aceita qualquer conexão) e precisa de um backend que valide o seu front antes de deixar chegar no banco. Mais backup, mais segurança. O Supabase abstrai tudo isso. Por isso ele é bom pra prototipar.

Apuração minha, pra você ver as peças com nome: a documentação de arquitetura do Supabase mostra que cada projeto é um Postgres cercado de serviços. O PostgREST transforma o banco numa API REST, o GoTrue cuida de usuário e token de acesso, e tem ainda o Realtime e o Storage. É exatamente a lista do parágrafo de cima, entregue pronta. (Na gravação eu chutei o número da porta de cabeça e errei: a documentação do PostgreSQL diz que o padrão é a 5432.)

Risco 1, o financeiro: travado no fornecedor e pagando por uso

O primeiro risco é o que a gente chama de vendor lock-in: eu estou ficando travado no fornecedor. Estou criando um sistema com uma trava gigantesca naquele cara. A partir do momento em que você começa a usar todas as facilidades ("legal, vou usar o login deles; legal, vou usar o banco HTTP; legal, vou usar o storage"), você está prendendo a sua aplicação inteira a ele.

"Não, Josimar, eu faço e depois dou um dump do Postgres e subo o meu." Ok, o banco sai. A parte de login não dá. Se você não tem controle do seu próprio login e usa o deles, no momento em que quiser sair você tem que refazer toda a parte de login. Storage é a mesma conversa: pode usar o deles, pode usar um S3 de quem você quiser. O importante é ter plano B.

• Banco: sai com dump do Postgres. É a peça mais fácil de levar embora.
• Login: é a peça que prende. Usou o deles, saiu, refaz.
• Storage: dá pra nascer num S3 que não seja o do mesmo fornecedor.
• Proxy e validação: o que ele abstrai hoje é o backend que você vai ter que escrever amanhã.

Eu não subiria uma aplicação pra produção dependendo de apenas um fornecedor. Sob hipótese alguma. Sobre o outro lado dessa mesma moeda, que é cair e vazar junto com todo mundo que usa a mesma peça, eu já escrevi em por que eu não uso GitHub, Supabase ou Firebase em produção. Aqui o assunto é a conta e a rede.

E a conta é esta: fica muito caro. Se você subir um Postgres direto na Amazon, já é caro. No Supabase você paga a Amazon e ainda paga os desenvolvedores dele. O planinho de entrada não dá pra nada em produção. Quando você vincula o banco de dados à sua aplicação desse jeito, vai ficar muito caro na hora de crescer, e pra sair vai ser um trauma.

Na gravação eu falei de um planinho de 5 dólares e avisei que nem sabia se ainda era isso. Fui conferir. Apuração minha, na tabela oficial de preços do Supabase, em 08/10/2026:

Repare em duas coisas. Primeira: a tabela de hoje diz que requisição de API é ilimitada; a régua da cobrança é usuário ativo, tráfego, disco e computação. Na gravação eu falei em requisição e em 500 usuários; a unidade é outra, e o ponto continua de pé: a conta cresce com o uso e não é você que define a unidade. Segunda: plano gratuito que pausa depois de uma semana parado é plano de protótipo. É a própria tabela dizendo pra que ele serve.

A gente está numa era fácil de empreender. Você valida, o projeto está funcionando, aí resolve liberar teste grátis pro seu usuário. De repente vem a pancada. Tem a galera que ganha cupom, incentivo de startup; eu estou falando do cenário normal. É a mesma armadilha que eu descrevi em o golpe do microSaaS de 2 dias: o que roda no protótipo não é o que aguenta cliente.

Risco 2, o de performance: 131 ms é uma eternidade pra banco

Segundo risco: performance. Um banco de dados remoto via HTTP é muito mais lento do que um banco de dados local. Fato. Gente, isso é engenharia de rede, não tem segredo.

Vou te dar o meu número. Eu tenho link dedicado entre o meu data center no Brasil e o de Miami, nos Estados Unidos. Conexão direta, trânsito bom. A latência entre os dois é de 131 milissegundos. Isso, pra um banco de dados, é uma eternidade. Latência local é 10, 20 milissegundos.

Faz a conta comigo (a conta é minha, em cima do número acima): uma tela que dispara 10 consultas em sequência gasta 10 × 131 ms = 1,31 segundo só de rede, antes de o banco trabalhar. No ambiente local, as mesmas 10 consultas gastam de 0,1 a 0,2 segundo. O usuário sente isso em toda tela.

"Ah, Josimar, mas a aplicação tem que conectar no backend de qualquer jeito." Perfeito. Ainda assim: usuário no Brasil conectando numa API do cloud deles lá fora. "Então eu monto uma instância aqui no Brasil." Aí sobra a volta que o HTTP dá: ou o seu front fala direto com a API deles, ou você constrói o seu backend pra conversar com ele, e a requisição passa duas vezes. Não dá pra ter banco de dados remoto num ambiente de produção legal.

Apuração minha, porque aqui tem nuance. A documentação de conexão do Supabase separa os caminhos: aplicação de front-end usa a Data API, que funciona por REST ou GraphQL; um backend persistente, numa VM ou num contêiner de longa duração, pode usar conexão direta ao Postgres, sem HTTP no meio. Ou seja: o caminho lento que eu descrevi é o do front falando com o banco pela API, que é justamente o uso que vende a ferramenta. Com backend seu e conexão direta, o que sobra é a distância entre o seu backend e o banco. E aí vale a minha régua: banco e aplicação no mesmo lugar.

Risco 3, a LGPD: dado de brasileiro fora do Brasil

"Não, Josimar, eu vou subir a minha versão na AWS." Se você usar um provisionador de infraestrutura, ou for na mão mesmo, dando next, next, next, e subir nos Estados Unidos, já é bomba. Dentro da Lei Geral de Proteção de Dados, a não ser que você entenda a lei e tenha um jurídico muito forte nela, não é o ideal subir dado de brasileiro em ambiente fora do Brasil. Começa por aí.

A não ser que você peça autorização explícita. Sabe aquele aviso de cookie que você não leva a sério? Ele tem fundamento. Se um dia você tomar uma notificação, vão validar se aquele aviso funciona, se a pessoa aceitou ou não. Aí o bicho começa a pegar. E pra quem atende governo: você não pode fazer isso, sob hipótese alguma, se não estiver explícito no contrato. Fora a pergunta básica: como é que você protege o dado de um cliente num banco que está lá, vai saber onde?

Apuração minha, com a lei na mão. O artigo 33 da LGPD (Lei 13.709/2018) diz que a transferência internacional de dados pessoais somente é permitida nos casos que ele lista. Entre eles: país com grau de proteção adequado; garantias como cláusulas-padrão contratuais; e quando o titular dá consentimento específico e em destaque pra transferência, com informação prévia sobre o caráter internacional da operação. Não é proibido, é condicionado. E as cláusulas-padrão têm texto oficial: saíram na Resolução CD/ANPD nº 19, de 23 de agosto de 2024, que aprovou o Regulamento de Transferência Internacional de Dados.

Segunda apuração, a favor da ferramenta: a lista de regiões do Supabase inclui South America (São Paulo), sa-east-1. Então dá pra manter o banco no Brasil. Só que é uma escolha sua na hora de criar o projeto, e muita gente nem olha. E existe o self-hosting oficial com Docker, que a própria documentação indica pra quem precisa de controle total do dado ou tem exigência de conformidade. Com o aviso junto: aí provisionamento, manutenção e segurança do servidor passam a ser responsabilidade sua. Voltamos pra infraestrutura. Sobre soberania de dado eu fui mais fundo em cabo submarino e soberania de dados.

"Mas eu sou dev sozinho e não sei cuidar de infraestrutura"

Ok. Avalie as possibilidades antes de se vincular somente a esse fornecedor. E, de outro lado, estude o mínimo de infraestrutura. Eu entendo: infraestrutura dói. Subir uma VM pra montar um Postgres dói, porque não é só o Postgres. É banco, segurança, rollback, backup, redundância.

Então, amigo vibe coder, seja mobile ou front-end: na hora de arquitetar a aplicação, você já pensa em como vai migrar pra outro lugar. Pode ser outro backend as a service, pode ser um Postgres gerenciado em que você confie. Dá pra subir na Amazon, no Google Cloud ou no Azure; todos têm opção de Postgres com escala automática. (Sobre apertar esse botão sem preparar a aplicação, leia autoscale não salva aplicação mal feita.) Ainda assim, a Amazon é muito cara. Pra quem ainda não gasta dezenas de milhares de reais com infraestrutura, usar nuvem faz todo o sentido. O que não faz sentido é não ter saída.

E hoje você tem ajuda pra isso: o Claude Code consegue te ajudar a criar um backendzinho de segurança, com URL validada, pra você não ser extorquido quando subir pra produção. Porque é isso que vai acontecer se você não planejar.

Quando faz sentido ter o próprio ambiente

Pra muita empresa, o que eu estou falando faz todo o sentido. O cara que gasta 10, 15, 20 mil por mês de AWS já começa a ter motivo pra montar um ambiente parecido com o meu, guardadas as devidas proporções: proteção, redundância, gastar menos dinheiro e total e completa soberania.

Esse tipo de ambiente te privilegia de outras formas. Eu não tenho só o meu banco de dados local. Eu tenho o meu S3 próprio, local. Eu tenho a minha GPU própria, que eu comprei e paguei uma vez. Eu não estou pagando por requisição, eu não estou alugando. Lógico que isso é uma conta mais complexa, que tem que ser feita caso a caso; aqui eu trouxe uma visão superficial. O caminho de entrada eu contei em pare de pagar VM na nuvem.

Se você quer aprender isso de verdade (banco com redundância, backup, S3 próprio, georredundância, do zero até subir uma aplicação), é o conteúdo da minha imersão de infraestrutura, presencial em São Paulo, três dias, comigo e com a minha equipe. Nota de cronologia: na gravação, de junho, eu falei de faixa de preço e avisei que ainda não tinha data. Não vou repetir número de gravação antiga aqui; o que vale é o que está na página da imersão hoje.

Minha régua: prototipa, valida e já entra sabendo como sai

Na gravação eu chamei isso de três formas de matar o próprio projeto, e fiz trocadilho com o nome da ferramenta. Tirando a piada, a régua é simples. Supabase, na minha concepção, é feito pra prototipar, e nada vai tirar isso da minha ideia. Pode jogar o seu projeto lá, pode validar, pode ver se funciona.

Na hora de escalar, o cenário normal é este: você põe um negócio desses em produção e está correndo três riscos reais, o financeiro, o de performance e o de LGPD. Testa, valida e vai pra um local bacana que você consiga subir. E performance, gente, pelo amor de Deus: performance do usuário. Um abraço, e até a próxima. Tem mais dessa linha aqui no blog.

Perguntas frequentes