Melhor Banco de Dados para Sites com 100K+ Registros: Supabase vs Firebase vs PlanetScale Testado
Supabase vs Firebase vs PlanetScale vs Neon vs Turso para Aplicações com 100K+ Registros
A maioria dos artigos "Supabase vs Firebase" são escritos por pessoas que criaram um app de tarefas em cada plataforma e chamaram de pronto. Eu tenho executado 253.000+ registros em cinco websites de produção no Supabase PostgreSQL por mais de um ano. Avaliei Firebase Firestore, PlanetScale, Neon e Turso para projetos reais de clientes -- não hipotéticos. Isto é o que realmente descobri.
Se você está construindo uma aplicação web que precisa lidar com 100K+ registros com queries complexas, recursos em tempo real e autenticação, sua escolha de banco de dados definirá sua arquitetura por anos. Escolha errado e você está reescrevendo sua camada de dados em seis meses ou pagando 3x o que deveria. Quero salvá-lo de ambas as situações.
Índice
- Por Que Esta Comparação Existe
- Os Concorrentes em Resumo
- Supabase PostgreSQL: Nosso Cavalo de Carga em Produção
- Firebase Firestore: Onde Vence e Onde Perde
- PlanetScale: Ótimo Banco de Dados, Plataforma Incompleta
- Neon: A Escolha do Purista
- Turso: SQLite Orientado à Edge
- Comparação de Recursos Lado a Lado
- Benchmarks de Performance com 100K+ Registros
- Análise de Preços para Cargas de Trabalho com 100K Registros
- Qual Banco de Dados Você Deve Escolher?
- FAQ
Por Que Esta Comparação Existe
Na Social Animal, construímos aplicações web headless -- principalmente com Next.js e Astro -- para clientes que precisam de sites dinâmicos e com muitos dados. Pense em diretórios empresariais com 50K+ listagens, sites de SEO programático gerando milhares de páginas e painéis SaaS que precisam de atualizações em tempo real.
Quando um cliente chega até nós com um projeto envolvendo 100K+ registros, a conversa sobre banco de dados acontece no primeiro dia. Não é um pensamento tardio. Sua escolha de banco de dados se propaga através de sua estratégia de autenticação, seu design de API, seus custos de hospedagem e sua capacidade de entregar features daqui a seis meses.
Não vou fingir que executei cargas de trabalho de produção idênticas em todos os cinco bancos de dados. Isso seria desonesto. O que fiz foi executar produção séria no Supabase (253K+ registros, cinco sites, 14 meses) e fazer avaliações técnicas minuciosas das alternativas para projetos específicos de clientes. Serei claro sobre quais dados vêm de produção e quais vêm de avaliação.
Os Concorrentes em Resumo
Antes de aprofundarmos, aqui está o quadro rápido:
- Supabase -- PostgreSQL com todas as baterias incluídas (auth, storage, realtime, edge functions)
- Firebase Firestore -- Banco de dados NoSQL de documentos do Google com excelentes SDKs para mobile
- PlanetScale -- MySQL serverless com database branching (powered by Vitess)
- Neon -- PostgreSQL serverless com branching e scale-to-zero
- Turso -- SQLite distribuído na edge (powered by libSQL)
Cada um é genuinamente bom em algo. A questão é se isso algo combina com o que você está construindo.
Supabase PostgreSQL: Nosso Cavalo de Carga em Produção
Vou começar com Supabase porque é onde temos a experiência mais profunda. Em cinco sites de produção, nossa tabela maior tem 137K linhas (um sistema de endereços nacional para um projeto de diretório), e estamos em 253K+ registros totais em todos os bancos de dados.
O Que Usamos Diariamente
Row Level Security (RLS) é provavelmente o recurso que selou o acordo para nós. Quando você está construindo aplicações multi-tenant -- que a maioria dos sites driven por headless CMS eventualmente se torna -- você precisa isolamento de dados por usuário. Com RLS, a lógica de segurança vive no banco de dados em si. Sua camada de API não precisa se lembrar de filtrar por user_id em cada query individual. O banco de dados o impõe.
Aqui está como uma política RLS típica fica em nossos projetos:
-- Usuários podem ver apenas as listagens de sua própria organização
CREATE POLICY "org_isolation" ON listings
FOR SELECT
USING (org_id = (SELECT org_id FROM profiles WHERE id = auth.uid()));
-- Admins podem ver tudo
CREATE POLICY "admin_access" ON listings
FOR ALL
USING (EXISTS (
SELECT 1 FROM profiles
WHERE id = auth.uid() AND role = 'admin'
));
Isto é SQL real. Não é uma DSL proprietária. Se você precisar sair do Supabase, estas políticas se traduzem para qualquer host PostgreSQL.
pgvector foi uma revelação para busca semântica. Implementamos em um site com muito conteúdo onde a busca full-text tradicional não estava funcionando. Usuários procurariam por "lugares para comer perto do centro" e esperariam resultados que incluíssem restaurantes, cafés e food trucks -- mesmo se essas palavras exatas não estivessem na listagem.
-- Criar a coluna de vetor
ALTER TABLE listings ADD COLUMN embedding vector(1536);
-- Criar o índice (isto importa MUITO com 100K+ registros)
CREATE INDEX ON listings USING ivfflat (embedding vector_cosine_ops)
WITH (lists = 100);
-- Query de busca semântica
SELECT id, name, 1 - (embedding <=> $1) AS similarity
FROM listings
WHERE 1 - (embedding <=> $1) > 0.78
ORDER BY embedding <=> $1
LIMIT 20;
Com 137K registros com vetores de dimensão 1536, esta query retorna em ~45ms no plano Pro do Supabase. Isto é rápido o suficiente para busca em tempo real conforme você digita.
PostGIS geo-queries alimentam nossos recursos baseados em localização. Encontrar listagens dentro de um raio, ordenar por distância, calcular tempos de trajeto -- tudo manipulado no nível do banco de dados em vez de código de aplicação.
-- Encontrar listagens dentro de 10km de um ponto, ordenadas por distância
SELECT id, name,
ST_Distance(location, ST_MakePoint(-73.9857, 40.7484)::geography) AS distance_m
FROM listings
WHERE ST_DWithin(
location,
ST_MakePoint(-73.9857, 40.7484)::geography,
10000
)
ORDER BY distance_m
LIMIT 50;
Assinaturas Realtime nos permitem construir painéis ao vivo sem infraestrutura WebSocket. Um painel de administrador do cliente mostra novas submissões aparecendo instantaneamente porque assinamos eventos INSERT na tabela relevante. Zero infraestrutura adicional.
O Que Não É Perfeito
Não vou fingir que Supabase é impecável. O dashboard pode ser lento quando você está navegando tabelas com 100K+ linhas. O editor de tabelas é bom para pequenos datasets mas doloroso para operações em massa -- você querrá usar SQL diretamente. Suas Edge Functions são powered by Deno, o que significa que alguns pacotes Node.js não funcionam. E se você precisar de connection pooling para ambientes serverless, você precisa usar sua string de conexão Supavisor (eles descontinuaram PgBouncer a partir do início de 2025).
Também, seu tier grátis é genuinamente generoso para desenvolvimento mas tem um limite rígido de 500MB de espaço em banco de dados. Para produção com 100K+ registros, você está olhando para o plano Pro no mínimo ($25/mês).
Firebase Firestore: Onde Vence e Onde Perde
Avaliamos Firebase seriamente para dois projetos de clientes em 2024. Um era uma aplicação mobile-first com requisitos de sincronização offline. O outro era um site de diretório com filtragem complexa.
Onde Firebase Genuinamente Vence
A sincronização em tempo real do Firebase para aplicações mobile ainda é a melhor da categoria. A persistência offline, resolução automática de conflitos e integração estreita com SDKs iOS/Android fazem dela a escolha óbvia se sua plataforma principal é mobile. A integração com Google Auth é extremamente simples -- algumas linhas de código e você tem Sign-in com Google, Apple, número de telefone e email/senha.
Firebase Crashlytics, Remote Config e Analytics formam um ecossistema de desenvolvimento mobile que nada mais se compara. Se você está construindo um app mobile primeiro e um app web segundo, Firebase merece consideração séria.
Por Que Escolhemos Supabase Em Vez Disso
Firestore é um banco de dados de documentos. Nenhum join. Deixe isto afundar por um momento.
Quando você está construindo um diretório com listagens que têm categorias, tags, localizações, avaliações e perfis de usuários, você precisa de dados relacionais. No Firestore, você ou desnormaliza tudo (duplicando dados entre documentos e rezando para manter sincronizado) ou faz múltiplas queries de ida e volta e une os dados no código de aplicação.
Aqui está como uma query "encontrar listagens por categoria com avaliação média" fica em cada um:
-- Supabase: uma query, pronto
SELECT l.*, c.name AS category_name,
AVG(r.rating) AS avg_rating,
COUNT(r.id) AS review_count
FROM listings l
JOIN categories c ON l.category_id = c.id
LEFT JOIN reviews r ON r.listing_id = l.id
WHERE c.slug = 'restaurants'
GROUP BY l.id, c.name
ORDER BY avg_rating DESC
LIMIT 20;
// Firestore: três queries + join do lado do cliente
const categorySnap = await db.collection('categories')
.where('slug', '==', 'restaurants').get();
const categoryId = categorySnap.docs[0].id;
const listingsSnap = await db.collection('listings')
.where('categoryId', '==', categoryId).get();
// Agora buscar avaliações para cada listagem...
// Então computar médias no código de aplicação...
// Então ordenar... você entendeu a ideia.
E aqui está o real problema: Firestore cobra por leitura de documento. Aquele padrão de triple-query acima? Cada documento em cada query conta. Com 100K+ registros e tráfego moderado, sua conta se torna genuinamente imprevisível. Ouvimos histórias de horror de contas de $400+ de surpresa de desenvolvedores que não perceberam que suas queries estavam varrendo mais documentos do que esperado.
Firestore também não tem equivalente a pgvector ou PostGIS. Você pode fazer queries geohash básicas, mas elas são aproximadas e limitadas comparado a indexação espacial verdadeira.
PlanetScale: Ótimo Banco de Dados, Plataforma Incompleta
PlanetScale executa Vitess debaixo do capô -- a mesma tecnologia que alimenta o banco de dados do YouTube. Para puro desempenho MySQL, é excelente. Seu recurso de database branching (criar um branch, fazer mudanças de schema, mesclar de volta) é genuinamente inovador e algo que gostaria que Supabase tivesse nativamente.
O Que PlanetScale Faz Bem
Seu serverless driver é rápido. Gerenciamento de conexão é manipulado para você, o que importa enormemente em ambientes serverless onde cada invocação de função poderia de outra forma abrir uma nova conexão de banco de dados. Schema branching torna migrações de banco de dados parecerem pull requests do Git -- seguro, revisável, reversível.
Para equipes com forte expertise MySQL construindo aplicações web tradicionais, PlanetScale é sólido.
O Que Falta
PlanetScale é apenas um banco de dados. Isto é tudo. Compare o que você precisa para construir uma pilha de aplicação completa:
| Feature | Supabase | PlanetScale + Extras |
|---|---|---|
| Banco de Dados | ✅ Incluído | ✅ Incluído |
| Auth | ✅ Incluído | ❌ Precisa Clerk ($25+/mês) ou Auth0 |
| File Storage | ✅ Incluído | ❌ Precisa S3 ou Cloudflare R2 |
| Realtime | ✅ Incluído | ❌ Precisa Pusher ou Ably |
| Vector Search | ✅ pgvector | ❌ Não disponível |
| Geo Queries | ✅ PostGIS | ❌ MySQL spatial básico |
| Edge Functions | ✅ Incluído | ❌ Precisa deployment separado |
No momento em que você adicionou Clerk para auth, S3 para storage, Pusher para realtime e um deployment separado, você está gerenciando cinco serviços em vez de um. Sua conta é mais alta, sua complexidade é mais alta, e sua superfície de debugging é enorme.
PlanetScale também descontinuou seu tier grátis (Hobby plan) em abril de 2024, então o ponto de entrada agora é $39/mês para seu plano Scaler. Isto é mais caro que Supabase Pro e te dá menos funcionalidade.
Neon: A Escolha do Purista
Neon é o banco de dados que eu escolheria se precisasse apenas de PostgreSQL e nada mais. Sua arquitetura serverless é genuinamente impressionante -- scale-to-zero significa que você não paga nada quando seu banco de dados não está sendo consultado. Seu recurso de branching é excelente para deployments de preview (criar um branch de banco de dados para cada PR).
Neon suporta pgvector e PostGIS porque é PostgreSQL padrão. Então você obtém busca por vetor e geo queries. As capacidades de banco de dados bruto são quase idênticas ao Supabase.
Por Que Ainda Escolhemos Supabase
Neon é um banco de dados. Supabase é uma plataforma. Com Neon, você precisa adicionar:
- Auth -- Clerk, Auth0, ou criar seu próprio
- Storage -- S3, Cloudflare R2, ou similar
- Realtime -- Pusher, Ably, ou um servidor WebSocket customizado
- Edge Functions -- Fazer deploy no Cloudflare Workers ou Vercel separadamente
Para algumas equipes, essa abordagem modular é realmente preferível. Se você já tem opiniões sobre auth (e o orçamento para Clerk), usa S3 para tudo e não precisa de realtime, a abordagem focada do Neon significa menos lock-in de vendor.
Mas para nossos projetos de desenvolvimento headless, ter auth, storage e realtime em um dashboard com uma conta e um conjunto de API keys vale muito. Velocidade do desenvolvedor importa quando você está entregando projetos de cliente com timelines apertadas.
O preço do Neon também é competitivo: o tier grátis inclui 0.5GB de storage e 190 compute hours/mês. O plano Launch em $19/mês te dá 10GB. Para um jogo de banco de dados puro, é o melhor valor em PostgreSQL serverless.
Turso: SQLite Orientado à Edge
Turso é tecnologia fascinante. Eles pegaram SQLite -- o banco de dados mais deployado do mundo -- e o tornaram distribuído. Seus dados vivem na edge, perto de seus usuários, o que significa que latência de leitura pode ser incrivelmente baixa (sub-10ms globalmente).
Onde Turso Brilha
Cargas de trabalho pesadas em leitura com públicos globais. Se você está servindo conteúdo que não muda frequentemente para usuários em todo o mundo, replicação de edge do Turso te dá leituras de banco de dados que parecem instantâneas. Seu recurso de embedded replicas permite que você agrupe uma réplica SQLite diretamente em sua aplicação.
Para sites estáticos-ish com Astro que precisam de uma camada de dados leve, Turso é convincente.
Por Que Não Funcionou Para Nossas Necessidades
Nossas cargas de trabalho de 100K+ registros envolvem escritas significativas -- submissões de usuário, atualizações de admin, criação de revisão, mudanças de dados em tempo real. O modelo de escrita do SQLite (single-writer) se torna um gargalo em escala. Turso manipula isto melhor que SQLite bruto através de seu fork libSQL, mas ainda não é projetado para aplicações 100K+ registros pesadas em escrita.
Nenhuma busca por vetor. Nenhum equivalente PostGIS. Ecossistema limitado comparado a PostgreSQL ou MySQL. Para nossos projetos de diretório e SaaS, estes foram dealbreakers.
Comparação de Recursos Lado a Lado
Aqui está a tabela de comparação completa baseada em nossa experiência de produção e avaliações a partir de meados de 2025:
| Feature | Supabase | Firebase | PlanetScale | Neon | Turso |
|---|---|---|---|---|---|
| Tipo de Banco de Dados | PostgreSQL | NoSQL (Firestore) | MySQL (Vitess) | PostgreSQL | SQLite (libSQL) |
| Auth Built-in | ✅ Sim | ✅ Sim | ❌ Não | ❌ Não | ❌ Não |
| Vector Search | ✅ pgvector | ❌ Não | ❌ Não | ✅ pgvector | ❌ Não |
| Geo Queries | ✅ PostGIS | ⚠️ Limitado (Geohash) | ⚠️ MySQL spatial básico | ✅ PostGIS | ❌ Não |
| Realtime | ✅ Sim | ✅ Sim | ❌ Não | ❌ Não | ❌ Não |
| File Storage | ✅ Sim | ✅ Sim | ❌ Não | ❌ Não | ❌ Não |
| Edge Functions | ✅ Baseado em Deno | ✅ Cloud Functions | ❌ Não | ❌ Não | ❌ Não |
| Joins / Relations | ✅ SQL Completo | ❌ Sem joins | ✅ SQL Completo | ✅ SQL Completo | ✅ SQL (limitado) |
| Branching | ⚠️ Via migrations | ❌ Não | ✅ Nativo | ✅ Nativo | ❌ Não |
| Scale-to-Zero | ❌ Não | ✅ Sim | ✅ Sim | ✅ Sim | ✅ Sim |
| Previsibilidade de Preço | 🟢 Alta (flat tiers) | 🔴 Baixa (per-read) | 🟡 Média | 🟢 Alta | 🟢 Alta |
| Open Source | ✅ Sim | ❌ Não | ❌ Não (Vitess é) | ✅ Sim | ✅ Sim |
| Self-Hostable | ✅ Sim | ❌ Não | ❌ Não | ❌ Não | ✅ Sim |
Benchmarks de Performance com 100K+ Registros
Estes números vêm de nossa instância Supabase de produção (plano Pro, região us-east-1) com 137K linhas na tabela principal. Para os outros bancos de dados, estou usando benchmarks publicados e testes de avaliação com 100K registros sintéticos.
| Tipo de Query | Supabase | Firebase | PlanetScale | Neon | Turso |
|---|---|---|---|---|---|
| SELECT Simples por ID | 3ms | 8ms | 4ms | 5ms | 1ms |
| Query Filtrada (indexed) | 12ms | 15ms | 10ms | 14ms | 3ms |
| JOIN Complexo (3 tabelas) | 35ms | N/A (sem joins) | 28ms | 38ms | 25ms |
| Similaridade de Vetor (top 20) | 45ms | N/A | N/A | 42ms | N/A |
| Geo raio (10km) | 22ms | ~50ms (geohash) | N/A | 24ms | N/A |
| Full-text search | 18ms | N/A (use Algolia) | 15ms | 20ms | 12ms |
| Bulk INSERT (1000 linhas) | 180ms | 250ms | 150ms | 195ms | 320ms |
| Cold start (serverless) | N/A (sempre on) | ~100ms | ~50ms | ~300ms | ~20ms |
Algumas coisas se destacam. A performance de leitura do Turso é excepcional -- essa é a vantagem do SQLite-at-edge. O engine MySQL do PlanetScale manipula joins ligeiramente mais rápido que PostgreSQL em nossos testes. O cold start do Neon é notável (300ms) porque precisa acordar o compute, embora queries subsequentes sejam rápidas. A falta de joins do Firebase significa que você literalmente não pode rodar algumas destas queries.
O compute sempre-on do Supabase (sem scale-to-zero no Pro) significa zero cold starts, o que importa para aplicações que enfrentam os usuários onde aquele primeiro request não pode ser lento.
Análise de Preços para Cargas de Trabalho com 100K Registros
Vamos modelar uma aplicação realista de 100K-registros: um site de diretório com 100K listagens, 50K usuários ativos mensais, ~2M leituras de banco de dados/mês, ~50K escritas/mês, 5GB de tamanho de banco de dados, 10GB de armazenamento de arquivo.
| Supabase Pro | Firebase (Blaze) | PlanetScale Scaler | Neon Launch | Turso Scaler | |
|---|---|---|---|---|---|
| Custo Base | $25/mês | $0 (pay-as-you-go) | $39/mês | $19/mês | $29/mês |
| Banco de Dados | Incluído (8GB) | ~$18 (reads + writes) | Incluído (10GB) | Incluído (10GB) | Incluído (9GB) |
| Auth | Incluído (50K MAU) | Incluído | +$25/mês (Clerk) | +$25/mês (Clerk) | +$25/mês (Clerk) |
| Storage (10GB) | Incluído | ~$3/mês | +$2/mês (R2) | +$2/mês (R2) | +$2/mês (R2) |
| Realtime | Incluído | Incluído | +$25/mês (Pusher) | +$25/mês (Pusher) | +$25/mês (Pusher) |
| Total Estimado | $25/mês | ~$21/mês | ~$91/mês | ~$71/mês | ~$81/mês |
Firebase parece barato até você perceber duas coisas. Primeiro, aquela estimativa de $21 assume padrões de leitura previsíveis. Um momento viral ou um bot rastreando seu site pode aumentar leituras dramaticamente -- e sua conta aumenta com isso. Segundo, uma vez que você precisar de features como vector search, você está adicionando Pinecone ou Weaviate, que começam em $70/mês.
O flat $25/mês do Supabase para tudo -- banco de dados, auth, storage, realtime, edge functions -- é valor notavelmente bom para este tamanho de carga de trabalho. O plano Pro inclui 8GB de banco de dados, 250GB de bandwidth, 100GB de storage e 50K usuários ativos mensais para auth.
Qual Banco de Dados Você Deve Escolher?
Aqui está minha recomendação honesta baseada em construir com estas ferramentas:
Escolha Supabase se você está construindo uma aplicação web com dados relacionais, precisa de auth + storage + realtime em uma plataforma, quer o ecossistema do PostgreSQL (pgvector, PostGIS, full-text search), ou você está construindo com Next.js. Isto cobre provavelmente 80% dos projetos que vemos.
Escolha Firebase se você está construindo uma aplicação mobile-first onde sincronização offline importa, sua equipe já conhece o ecossistema Firebase, ou seus dados são realmente de forma de documento (mensagens de chat, feeds de atividade, perfis de usuário simples).
Escolha PlanetScale se você tem uma equipe MySQL forte, precisa de database branching para gerenciamento complexo de schema, e você já está usando serviços separados para auth e storage. É um ótimo banco de dados -- apenas não uma plataforma completa.
Escolha Neon se você quer PostgreSQL sem o overhead da plataforma, prefere montar sua própria pilha a partir de serviços best-of-breed, ou precisa de scale-to-zero para otimização de custo em projetos de tráfego baixo.
Escolha Turso se você está construindo uma aplicação leve em leitura, globalmente distribuída onde latência de edge importa mais que throughput de escrita, ou você está trabalhando com Astro em sites focados em conteúdo.
Para nosso trabalho na Social Animal construindo aplicações web headless, Supabase foi a chamada certa. A plataforma all-in-one significa desenvolvimento mais rápido, arquitetura mais simples e custos previsíveis. Escalamos para 253K+ registros sem suar frio. Se você está planejando um projeto nesta escala e quer conversar sobre arquitetura, entre em contato conosco -- fizemos isto algumas vezes agora.
FAQ
Supabase é bom para aplicações em larga escala? Sim, e temos evidência de produção para apoiar isto. Estamos executando 253K+ registros em cinco sites de produção no Supabase Pro. A performance de query permanece consistente -- nossos joins mais complexos com vector similarity search retornam em menos de 50ms em 137K linhas. Supabase executa em PostgreSQL padrão, que alimenta aplicações ordens de magnitude maiores do que qualquer coisa que a maioria de nós construirá. A camada de plataforma (auth, storage, realtime) é a parte que é mais nova, mas foi estável para nós desde o início de 2024.
Como a precificação do Supabase se compara ao Firebase em escala? Supabase é dramaticamente mais previsível. Seu plano Pro é um flat $25/mês que inclui auth para 50K MAUs, 8GB de storage de banco de dados, 250GB de bandwidth e 100GB de armazenamento de arquivo. Firebase cobra por leitura, escrita e exclusão de documento -- o que torna os custos altamente variáveis. Uma aplicação de 100K-registros com 2M leituras mensais poderia custar em qualquer lugar de $15 a $200+ no Firebase dependendo de padrões de query. Vimos contas Firebase triplicarem da noite para o dia quando uma página é compartilhada em mídia social.
PlanetScale pode manipular 100K+ registros? Absolutamente. PlanetScale executa Vitess, que alimenta cargas de trabalho em escala YouTube. Para puro desempenho de banco de dados com 100K registros, PlanetScale é excelente. A limitação não é escala -- é completude. Você precisará adicionar serviços separados para auth, file storage, atualizações em tempo real e vector search. Isto adiciona ambos os custos ($90+/mês total) e complexidade arquitetural comparado à abordagem all-in-one do Supabase.
O que é pgvector e por que importa? pgvector é uma extensão PostgreSQL que armazena e consulta embeddings de vetor diretamente em seu banco de dados. Isto habilita busca semântica -- usuários podem buscar por significado em vez de palavras-chave exatas. Para um diretório com 100K+ listagens, isto significa uma busca por "brunch kid-friendly spots" pode retornar resultados marcados como "family restaurant" ou "weekend breakfast" mesmo que essas palavras não combinem. Sem pgvector, você precisaria de um banco de dados de vetor separado como Pinecone ($70+/mês) e lidar com manter dois bancos de dados sincronizados.
Firebase Firestore é bom para websites de diretório? Honestamente, não. Websites de diretório são inerentemente relacionais. Listagens pertencem a categorias, têm tags, recebem avaliações de usuários e precisam de filtragem complexa ("mostre-me restaurantes dentro de 5 milhas com 4+ estrelas que estão abertos agora"). Firestore não pode fazer joins, tem operadores de query limitados e cobra por leitura de documento -- o que significa que queries filtradas complexas ficam caras rápido. Avaliamos Firestore para um projeto de diretório e estimamos 4x o tempo de desenvolvimento comparado ao Supabase devido a desnormalização de dados e workarounds de query do lado do cliente.
Devo usar Neon ou Supabase para meu app Next.js? Se você precisa apenas de um banco de dados, Neon oferece melhor valor (tier grátis é generoso e o plano Launch de $19/mês é sólido). Se você precisa de auth, storage, realtime ou edge functions -- que a maioria dos apps Next.js de produção faz -- Supabase economiza você de integrar e pagar por múltiplos serviços separados. Usamos Supabase para nossos projetos de desenvolvimento Next.js porque a auth integrada e storage cortam semanas dos timelines de projeto típicos.
Qual é o melhor banco de dados para sites de SEO programático? Supabase PostgreSQL. Sites de SEO programático geram milhares de páginas a partir de dados estruturados, o que significa que você precisa de queries rápidas, bom indexing e a capacidade de manipular relações de dados complexas. Construímos sites de SEO programático no Supabase que geram 10K+ páginas a partir de um único banco de dados -- PostGIS para páginas de localização, pgvector para conteúdo relacionado e full-text search para filtragem dinâmica. A precificação flat significa que picos de tráfego de indexação do Google não explodem sua conta.
Turso (libSQL) está pronto para aplicações web de produção? Para aplicações pesadas em leitura, sim. SQLite replicado de edge do Turso te dá leituras sub-5ms globalmente, o que é incrível para sites focados em conteúdo. Mas para aplicações pesadas em escrita com 100K+ registros -- como diretórios onde usuários submetem dados, painéis de admin processam atualizações e avaliações entram constantemente -- o modelo single-writer do SQLite se torna limitante. Recomendaríamos Turso para sites de conteúdo construídos com Astro e Supabase ou Neon para aplicações dinâmicas com cargas de trabalho significativas de escrita.