Supabase ou Firebase: o formato da consulta pode triplicar a fatura

Para um MVP com catálogo relacional e telas consultadas com frequência, o Supabase costuma ser o ponto de partida mais simples para modelar os dados e estimar o custo. Se os registros são documentos independentes e o uso é irregular, o Cloud Firestore pode se encaixar melhor. Em ambos os casos, a escolha depende das consultas que cada tela fará, não apenas do número de usuários.

Uma mudança pequena na interface pode alterar essa conta. A Marfin relata que sua fatura do Firestore triplicou em um mês depois que a página inicial passou a carregar um feed de cem itens. Trata-se da experiência de uma empresa, sem dados suficientes para projetar o mesmo aumento em outro aplicativo. O caso identifica a variável decisiva: quantos registros cada visita passa a buscar.

O que cada plataforma cobra

No Cloud Firestore, a documentação de cobrança inclui documentos lidos, escritos e excluídos, armazenamento, tráfego de saída e entradas de índice lidas para atender determinadas consultas. Em geral, a leitura de índices é cobrada por lote de até mil entradas; consultas com no máximo um campo de intervalo ficam isentas dessa parcela. A cota gratuita de uma base elegível inclui 50 mil leituras de documentos por dia. Como ela é diária, dividir um total mensal por trinta pode esconder dias em que o limite foi ultrapassado; os preços pagos também dependem da localização da base.

No Supabase, uma resposta com mais linhas não cria, por si só, uma tarifa por documento retornado. A tabela de preços do Supabase apresenta o Pro a partir de US$ 25 mensais, com US$ 10 em créditos de computação suficientes para uma instância Micro, 8 GB de disco de banco e 250 GB de saída de dados não armazenados em cache; o excedente dessa saída custa US$ 0,09 por GB. Computação maior, disco adicional e outros serviços podem elevar a conta. Uma consulta que devolve muitos bytes ou exige mais capacidade do Postgres continua tendo custo, ainda que o número de linhas não seja uma unidade tarifada.

Catálogo relacional: leituras ou dados repetidos

Considere uma carga hipotética: mil visitas por dia, durante trinta dias, a uma página que mostra vinte livros. Se cada livro for um documento do Firestore e o cliente buscar todos a cada visita, o resultado será de 20 mil leituras diárias, ou 600 mil no período. Acrescentar cinco buscas de documentos de categoria por visita leva a estimativa a 25 mil leituras por dia e 750 mil no mês. São contas de operações, não uma previsão de preço: outras telas, leituras de regras de segurança, índices e tráfego ainda podem entrar na fatura.

É possível copiar o nome da categoria para cada livro e evitar aquelas buscas adicionais. O preço dessa decisão aparece quando a categoria muda: todos os livros que guardam uma cópia precisam ser atualizados. O modelo de dados do Firestore organiza registros em documentos e coleções, sem tabelas e linhas relacionais. Por isso, trazer um atributo relacionado em outra leitura ou mantê-lo duplicado são escolhas concretas de modelagem e cobrança.

No Supabase, livros e categorias podem ocupar tabelas ligadas por uma chave e chegar juntos em uma resposta. Para a mesma carga hipotética, trinta mil visitas mensais multiplicadas pelo tamanho da resposta estimam a saída de dados; o desempenho da consulta e o espaço ocupado pelas tabelas e índices orientam o dimensionamento da instância. A relação fica registrada em um lugar, mas uma junção mal dimensionada pode exigir mais computação. Se o catálogo reúne muitos vínculos que mudam com frequência, esse trabalho de modelagem pesa tanto quanto a primeira fatura.

Feed: a quantidade carregada muda a escala

Em uma segunda carga hipotética, a página inicial recebe mil visitas diárias por trinta dias. Um feed de trinta documentos gera 30 mil leituras por dia, ou 900 mil no mês, caso cada visita busque todos os itens. Ampliá-lo para cem documentos leva a 100 mil leituras diárias e 3 milhões mensais. Considerado isoladamente, o primeiro cenário fica abaixo da cota diária gratuita de leituras de documentos; o segundo a ultrapassa. Se catálogo e feed fizerem parte do mesmo aplicativo, suas leituras se somam, assim como as de outras telas.

O aumento de trinta para cem itens multiplica as leituras desse feed por cerca de 3,3, mas não determina a variação da fatura inteira. No Supabase, a mesma alteração eleva o trabalho da consulta e os bytes enviados. Se cada item da resposta tivesse, por hipótese, 1 KB, a página passaria de cerca de 30 KB para 100 KB de dados desses itens. Em trinta mil visitas, isso representaria aproximadamente 0,9 GB ou 3 GB, antes de outros campos, cabeçalhos e tráfego. Esses volumes ajudam a dimensionar a saída; sozinhos, não medem a computação necessária.

Paginar reduz o carregamento inicial nas duas arquiteturas, mas as páginas seguintes continuam consumindo recursos quando são abertas. No Firestore, usar um cursor evita cobrar leituras por documentos simplesmente saltados; uma consulta com deslocamento pode cobrar também por eles. Assim, duas interfaces que mostram o mesmo total de itens ao longo da sessão podem produzir contas diferentes conforme a navegação e a forma de buscar a próxima página.

Tempo real: a atualização chega a quantos clientes?

A terceira carga hipotética é um aplicativo de reservas. Suponha cem clientes conectados, dez mudanças de assento por minuto durante uma hora diária e trinta dias de funcionamento. Isso produz 18 mil mudanças no período. Se cada mudança atualizar um documento presente no resultado acompanhado por todos os clientes em listeners do Firestore, ela poderá gerar 1,8 milhão de leituras de atualização. A estimativa ainda deixa de fora as leituras iniciais, reconexões, consultas de índice pertinentes e escritas que registram as reservas.

No Supabase Realtime, a unidade depende do mecanismo usado. Pelas regras de cobrança de mensagens, um evento Broadcast conta um envio mais uma mensagem para cada cliente inscrito que o recebe; mudanças do banco acompanhadas diretamente contam uma mensagem por cliente ouvinte. Se as 18 mil mudanças hipotéticas forem transmitidas por Broadcast a todos os cem clientes, serão 1,818 milhão de mensagens. O Pro inclui 5 milhões de mensagens mensais e cobra US$ 2,50 por pacote adicional de um milhão; essa carga isolada ficaria dentro da franquia.

Leituras do Firestore e mensagens do Supabase não têm o mesmo preço nem cobrem os mesmos recursos. Para reservas, também importam o volume enviado a cada cliente, o pico de conexões e a capacidade do banco que grava as alterações. Reduzir os destinatários de uma atualização pode diminuir as operações em ambas as plataformas, desde que cada cliente continue recebendo as mudanças necessárias à sua tela.

O custo de mudar de modelo depois

A escolha inicial também define onde ficará o trabalho se o MVP crescer. Num catálogo do Firestore que repete categorias em documentos, migrar para tabelas relacionadas exige decidir quais campos viram entidades próprias, transformar os registros e reescrever consultas. As regras de acesso e os mecanismos de atualização também precisam acompanhar o novo desenho. Exportar os dados resolve apenas uma parte da mudança.

No caminho inverso, um catálogo relacional levado para documentos exige escolher quais informações serão incorporadas a cada registro e quais serão buscadas separadamente. Isso afeta leituras, escritas e a manutenção de cópias. Para decidir o backend do MVP, vale comparar as consultas das telas centrais com as unidades que elas acionam: documentos e possíveis índices no Firestore; computação, disco, saída e mensagens no Supabase. Relações frequentes favorecem começar a avaliação pelo Postgres. Documentos independentes e acesso irregular podem favorecer o Firestore, desde que o orçamento acompanhe mudanças no feed e nos listeners.

Leia também:

• Vagas remotas triplicaram nos EUA — a empresa ainda decide quem pode trabalhar assim
• Autofix do GitHub agora memoriza correções — o padrão errado também pode voltar
• GitHub Actions troca o total exato por “2.500+” — ajuste suas consultas