Firexport / Blog

A edição que você escolhe ao criar um banco de dados do Firestore, Standard ou Enterprise, não pode ser trocada depois. Agora que o modo nativo da edição Enterprise está em disponibilidade geral (GA) desde abril de 2026, vale mais a pena começar apps novos no Enterprise. Com uma condição: você mesmo cuida dos índices e do acesso dos clientes.

Por que o Enterprise é o melhor ponto de partida

1. Não dá para trocar, então comece pela que menos trava

A edição é definida quando o banco de dados é criado e não muda. Trocar significa mover os dados para um banco novo, recriar os índices e as configurações de TTL e backup, e publicar uma versão do app que aponte para o banco novo (guia de migração).

Por isso, comece pelo lado em que é menos provável ficar travado. O que trava no Standard são recursos como busca, agregação e junções, contornados com migração ou mudança de estrutura. O que trava no Enterprise costuma ser um índice que falta: você implanta o índice sem mexer no código nem nos dados.

2. O mesmo código, mais consultas

O modo nativo do Enterprise usa os mesmos SDKs do Firebase e as mesmas consultas (operações Core) do Standard. where(), orderBy(), listeners onSnapshot(), o cache off-line e as regras de segurança funcionam igual, e ele oferece o emulador local, gatilhos do Cloud Functions (2ª geração), as mesmas regiões do Standard e o uso sem custo do plano Spark. A diferença está na ordenação: documentos com o mesmo valor de ordenação não são desempatados pelo ID, então, se você pagina com cursores, inclua o ID do documento no orderBy.

Além disso, vêm as consultas Pipeline. O que no Standard exigia contornos vira uma consulta só.

A busca de texto, a geoespacial e as atualizações e exclusões em massa (DML) chegaram à disponibilidade geral em outubro de 2026. Mas o Pipeline faz leituras pontuais: não tem listeners em tempo real nem modo off-line, e, no Pipeline, as regras de segurança só entendem filtros simples que comparam um campo com uma constante. Deixe as listas na tela e as atualizações ao vivo em consultas Core, use Pipeline para busca, agregação e relatórios, e rode Pipelines complexos no servidor (Admin SDK, Cloud Functions).

3. Leituras com índice custam menos

O Standard cobra pelo número de documentos; o Enterprise, pelos bytes lidos e gravados. São os preços de us-central1 em novembro de 2026.

• Leituras: ler por ID um documento de até 4 KiB custa um sexto no Enterprise, e até 24 KiB custa o mesmo ou menos. Consultas pagam também a leitura do índice: com um resultado custam um terço, e quanto mais resultados, mais se aproximam de um sexto.
• Gravações: criar um documento de 1 KiB sai mais barato no Enterprise com até 2 entradas de índice (US$ 0,78 por milhão) e mais caro a partir de 3 (US$ 1,04). Atualizações que mudam um campo indexado custam 2 unidades por entrada alterada, então encarecem antes.
• Exclusões: até o menor documento custa 1 unidade (US$ 0,26), então sempre sai mais caro que no Standard (US$ 0,10).

Se o seu app lê muito mais do que grava, o Enterprise sai mais barato. Se grava e exclui muito, faça antes essas contas com o tamanho dos seus documentos e o número de índices.

O preço: índices e acesso ficam por sua conta

O Standard só executa consultas que um índice consegue atender. Cada campo ganha um índice automático, e uma consulta que precisa de índice composto falha com um erro que traz o link para criá-lo. Assim, o custo de uma consulta depende só do número de resultados.

O Enterprise não cria índices e executa as consultas mesmo sem eles. Em troca, lê a coleção inteira e cobra pelos bytes lidos, e ordena na memória, o que pode esbarrar no limite de memória por consulta (128 MiB). Como não há erro, nada aparece enquanto você desenvolve com algumas dezenas de documentos; aparece quando os dados crescem.

Este é o custo de executar um milhão de vezes uma consulta que busca um usuário pelo nome de usuário. Os documentos têm 2 KiB; a primeira linha é o exemplo de preços do Google e a segunda, o mesmo cálculo com 100.000 documentos.

Um único índice faz uma diferença de 25.000 vezes no custo da mesma consulta (100.000 × 2 KiB ÷ 4 KiB = 50.000 unidades por consulta).

Outra pessoa também pode usar essa diferença. Se os clientes podem listar uma coleção, qualquer um pode adicionar um filtro num campo sem índice e fazer o Firestore varrer tudo o que tem permissão para ler. Como nada corresponde, o limit não ajuda, e as regras de segurança não conseguem bloquear um filtro acrescentado à consulta. No Standard, essa consulta simplesmente falha.

Quatro hábitos

1. Escreva o índice junto com a consulta. Para cada combinação de where e orderBy numa coleção que continua crescendo, adicione um índice ao firestore.indexes.json e implante com firebase deploy --only firestore:indexes. Isso inclui os índices de campo único que o Standard criava para você. Leituras por ID de documento não precisam de índice. Este é o índice para where('authorId', '==', uid).orderBy('createdAt', 'desc'):

   {
     "indexes": [
       {
         "collectionGroup": "posts",
         "queryScope": "COLLECTION",
         "fields": [
           { "fieldPath": "authorId", "order": "ASCENDING" },
           { "fieldPath": "createdAt", "order": "DESCENDING" }
         ]
       }
     ]
   }

2. Confira com o Query Explain antes de publicar. No console do Firebase, rode a mesma consulta no editor de consultas (Query Editor) da guia Dados (Data) do Firestore e abra a guia Query Explain. Se a base da árvore de execução for TableScan, a coleção inteira foi lida sem índice.
3. Restrinja o acesso dos clientes. Aplique o App Check para recusar solicitações que não venham do seu app e use regras de segurança para prender as leituras de lista a uma igualdade num campo indexado, como resource.data.ownerId == request.auth.uid. Assim, se alguém provocar uma varredura, ela fica dentro dos documentos daquele usuário.
4. Ative o Query Insights e alertas de orçamento. O Query Insights mostra suas consultas frequentes e o desempenho delas, o que indica onde falta um índice. No plano Blaze, configure também um alerta de orçamento do Cloud Billing.

Começando no Enterprise

No console do Firebase, abra o Firestore, clique em Criar banco de dados (Create database), escolha Enterprise e o modo nativo (Native mode), e defina um ID e um local. Deixe as atualizações em tempo real (Realtime Updates) ativadas, que é o padrão. Elas não podem ser alteradas depois, e um banco criado sem elas não aceita listeners. Depois disso, três coisas mudam em relação ao Standard.

1. Passe o ID do banco de dados no código. Um banco Enterprise é um banco que você nomeia; o (default) só existe no Standard. Os SDKs se conectam ao (default), a menos que você indique outro.

   // Web
   const db = getFirestore(app, 'app-db');
   
   // Android (Kotlin)
   val db = FirebaseFirestore.getInstance("app-db")
   
   // iOS (Swift)
   let db = Firestore.firestore(database: "app-db")
   
   // Flutter
   final db = FirebaseFirestore.instanceFor(
       app: Firebase.app(), databaseId: 'app-db');

2. Informe o banco de dados e a edição no firebase.json. Assim as regras e os índices são implantados nesse banco, e o emulador inicia como Enterprise. Crie o banco de dados primeiro no console. Se o banco informado não existir, o firebase deploy o cria por você, e o Firebase CLI 15.12 o cria nesse caso no modo de compatibilidade com o MongoDB, que os SDKs do Firebase não conseguem usar.

   {
     "firestore": {
       "database": "app-db",
       "edition": "enterprise",
       "rules": "firestore.rules",
       "indexes": "firestore.indexes.json"
     }
   }

3. O uso sem custo vai para o primeiro banco de dados criado, e só para ele. Se o projeto tem um banco Standard que você não usa, exclua-o antes de criar o Enterprise, para que o uso sem custo vá para o Enterprise.

Quando o Standard ainda é melhor

• Apps que já rodam no Standard. Não migre até realmente precisar do Pipeline.
• Projetos sem ninguém para cuidar de consultas e índices. O Standard se recusar a executar consultas sem índice é a sua rede de proteção.
• Apps cujos clientes leem diretamente coleções públicas grandes. Em listas públicas que as regras não conseguem restringir, qualquer um pode provocar uma varredura completa.
• Apps que gravam e excluem muito, ou que leem sobretudo documentos grandes. Passados os pontos de equilíbrio acima, o Standard sai mais barato.
• Quando você precisa de ferramentas que pressupõem o banco (default) ou o Cloud Functions de 1ª geração. Bancos Enterprise têm nome próprio, e os gatilhos de 1ª geração não os aceitam.

Fontes

• Edições do Firestore, comparação de edições no modo nativo, visão geral do modo nativo do Enterprise: diferenças de recursos, índices, ordenação e varreduras
• Preços do Enterprise, exemplos de preços de consultas, exemplos de preços de gravações e exclusões, preços do Firebase: preços e uso sem custo
• Migrar do Standard para o Enterprise, notas da versão do Firestore
• Primeiros passos com o Enterprise, gerenciar bancos de dados, configurações do banco de dados (REST), locais, cotas e uso sem custo
• Índices do Enterprise, formato JSON dos índices, Query Explain, Query Insights
• Regras de segurança para Pipeline, App Check, gatilhos do Cloud Functions, emulador