Firebase Firestore — o que é, documentos e coleções NoSQL

O que é Firebase Firestore

Firebase Firestore é um banco de dados NoSQL em nuvem lançado pelo Google em 2019 como sucessor do Realtime Database. O Firestore é construído sobre a infraestrutura do Google Cloud Spanner e Google Cloud Datastore, fornecendo consistência forte de dados dentro de uma única transação e replicação multirregional automática. O SDK oferece suporte a Android, iOS, Web (JavaScript), Flutter, Kotlin Multiplatform e Unity.

Evolução do Realtime Database

O Firestore foi anunciado no Google I/O 2017 como “Cloud Firestore” — uma solução que aborda as principais limitações do Realtime Database: falta de suporte a consultas complexas, incapacidade de dimensionar dados em vários nós e consistência fraca. De acordo com o Google (2026), o Firestore processa mais de 1 trilhão de solicitações por dia e é o banco de dados padrão para 80% dos novos projetos Firebase. No entanto, o Realtime Database continua relevante para cenários de latência ultrabaixa (jogos, edição colaborativa) devido à sua estrutura JSON direta.

Limites gratuitos do Firestore

O Firestore é oferecido em um modelo de pagamento conforme o uso com um generoso limite gratuito no plano Spark: 1 GB de armazenamento, 10 GB de tráfego de rede por mês, 50 mil operações de leitura, 20 mil operações de gravação e 20 mil operações de exclusão por dia. No plano Blaze, tudo isso é gratuito e os excessos são cobrados: $0,06 por 100 mil operações de leitura, $0,18 por 100 mil operações de gravação. De acordo com o Google (2026), 90% dos projetos permanecem dentro do limite gratuito.

Modelo de dados: coleções, documentos e campos

O modelo de dados do Firestore é organizado hierarquicamente: a raiz contém coleções, cada coleção contém documentos, cada documento contém campos (tipos primitivos, arrays, Map) e coleções aninhadas (subcoleções). A profundidade de aninhamento das coleções é ilimitada, mas um documento não pode conter diretamente outro documento — apenas por meio de uma referência (tipo Reference).

Coleções e documentos

Uma coleção é um contêiner de documentos com identificadores gerados automaticamente ou definidos pelo usuário. Cada documento é um objeto semelhante a JSON de até 1 MiB. Os campos de um documento podem ser strings, números, valores booleanos, arrays, Map, carimbos de data/hora (Timestamp), GeoPoints e referências a outros documentos (Reference). O tamanho do documento é limitado a 1 MiB, incluindo todos os nomes de campos.

Gravação em lote e transações

O Firestore oferece suporte a transações atômicas no nível do banco de dados. Uma transação pode ler e gravar vários documentos — o Commit aplica atomicamente todas as alterações ou nenhuma. Máximo de 500 operações por transação, tempo limite de 60 segundos. A gravação em lote (batch write) é uma operação de gravação atômica não transacional sem fase de leitura. As transações são essenciais para operações financeiras, reservas de assentos e gerenciamento de inventário.

Comparação entre Firestore e Realtime Database

Escolher entre Firestore e Realtime Database depende dos requisitos do projeto. Ambos os bancos de dados fazem parte do ecossistema Firebase, fornecem sincronização em tempo real e estão disponíveis em todas as plataformas, mas diferem fundamentalmente no modelo de dados, escalonamento e preços.

Principais diferenças

O Realtime Database armazena dados em uma única árvore JSON, o que é conveniente para estruturas simples, mas dificulta o escalonamento com aninhamento superior a 3 níveis. O Firestore usa um modelo de coleção-documento com fragmentação automática, permitindo escalar para milhões de documentos sem degradação de desempenho. De acordo com o Google (2026), o Firestore suporta até 10 mil conexões simultâneas a uma única coleção sem perda de velocidade, enquanto o Realtime Database suporta até 200 mil conexões a uma única instância.

Preços

O Realtime Database é cobrado com base nos dados transferidos (bytes baixados) e no número de conexões simultâneas. O Firestore é cobrado pelo número de operações (leitura, gravação, exclusão). Para aplicativos com atualizações pequenas e frequentes (chat, notificações), o Firestore geralmente é mais econômico — cada operação de gravação tem um preço fixo, independentemente do tamanho dos dados. Para aplicativos com leituras pouco frequentes de grandes volumes de dados, o Realtime Database pode ser mais barato.

Recomendação do Google (2026): use o Firestore como banco de dados padrão para novos projetos e o Realtime Database para jogos e aplicativos onde a latência mínima (menos de 50 ms) e a estrutura de dados plana são essenciais. Ambos os bancos de dados podem funcionar simultaneamente no mesmo projeto.

Consultas, índices e paginação no Firestore

As consultas do Firestore são executadas em coleções ou grupos de coleções com filtragem, classificação e limites. Ao contrário do Realtime Database, onde cada consulta percorre toda a árvore JSON com filtragem do lado do cliente, o Firestore executa todas as consultas no servidor usando índices pré-criados. Isso garante que a complexidade da consulta dependa apenas do tamanho do resultado, não do tamanho da coleção.

Tipos de consultas

O Firestore oferece suporte a filtragem por um ou vários campos (igualdade, intervalo, in, array-contains, array-contains-any), classificação crescente e decrescente, limites e cursores para paginação. Limitações: consultas compostas com filtragem em campos diferentes (where price > 10 AND where category == “books”) exigem um índice composto; consultas OR são proibidas (use in e array-contains-any) e consultas de desigualdade em campos diferentes não são permitidas.

data class Product(
    val name: String = "",
    val category: String = "",
    val price: Double = 0.0,
    val inStock: Boolean = false
)

suspend fun FirestoreRepository.queryProducts(): List<Product> {
    return firestore
        .collection("products")
        .whereEqualTo("category", "electronics")
        .whereGreaterThanOrEqualTo("price", 100.0)
        .whereLessThan("price", 500.0)
        .orderBy("price")
        .limit(20)
        .get()
        .await()
        .toObjects(Product::class.java)
}

Índices automáticos e compostos

O Firestore cria automaticamente índices para campos individuais — consultas de campo único funcionam sem qualquer configuração. Para consultas com dois ou mais campos (filtragem + classificação), são necessários índices compostos. Quando uma consulta é enviada pela primeira vez, o Firestore retorna um erro com um link para o console onde o índice pode ser criado com um clique. Máximo de 200 índices compostos por banco de dados. Os índices podem ser exportados e importados via Firebase CLI.

Integração do Firestore no Android

Conectar o Firestore a um aplicativo Android é feito de forma padrão via Firebase BOM. Após adicionar a dependência firebase-firestore-ktx, o objeto FirebaseFirestore fica disponível via getInstance() — sem chaves ou tokens adicionais. O Firestore usa o mesmo projeto Firebase que os outros serviços.

dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.1.0"))
    implementation("com.google.firebase:firebase-firestore-ktx")
}

// Inicialização
val db = FirebaseFirestore.getInstance()

Leitura e gravação de dados

O Firestore fornece dois modos de leitura: única (get) e em tempo real (addSnapshotListener). A leitura única recupera um documento uma vez — útil para configurações e ajustes. Um listener se inscreve nas alterações — qualquer atualização de documento entrega automaticamente os dados atualizados a todos os clientes conectados em tempo real. set() cria ou sobrescreve um documento, update() modifica apenas os campos especificados sem sobrescrever o documento inteiro.

De acordo com o Google (2026), aplicativos de médio porte (100 mil DAU) com Firestore em tempo real consomem cerca de 5 a 10 GB de tráfego de saída por mês. O uso do cache offline (Persistence Cache) reduz downloads repetidos em 60 a 70%, pois o SDK carrega apenas os documentos alterados quando a conexão é restabelecida.

Modo offline

O Persistence Cache é um mecanismo integrado do Firestore para trabalhar sem acesso à internet. O SDK armazena automaticamente em cache todos os documentos lidos no dispositivo (até 500 MiB no Android). Quando a conexão é perdida, as leituras continuam do cache e as gravações são enfileiradas. Quando a conexão é restabelecida, todas as operações pendentes são enviadas ao servidor e o cache é sincronizado com o servidor. Para controle de conflitos, use snapshot-metadata.hasPendingWrites e setOptions(ServerTimestampBehavior).

Regras de segurança e validação de dados

Security Rules é uma linguagem declarativa de controle de acesso para o Firestore que é executada no servidor do Google antes de cada operação de leitura ou gravação. As regras não exigem código do lado do servidor — elas são escritas no console do Firebase ou via Firebase CLI e versionadas por meio do Git. Cada operação é verificada em relação às regras e uma violação retorna um erro PERMISSION_DENIED.

Estrutura das regras

As Firestore Security Rules consistem em blocos match e expressões allow. match define o caminho para uma coleção ou documento, allow especifica as operações permitidas (read, write, create, update, delete) e uma condição — uma expressão semelhante a JavaScript que retorna um booleano. As regras podem verificar autenticação (request.auth), dados da solicitação (request.resource.data), dados existentes (resource.data), hora (request.time) e caminho (request.path).

rules_version = '2';

service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read: if request.auth != null;
      allow write: if request.auth.uid == userId;
    }

    match /products/{productId} {
      allow read: if true;
      allow create: if request.auth.token.role == "admin";
      allow update: if resource.data.authorId == request.auth.uid;
    }
  }
}

Validação de dados

As Security Rules oferecem suporte à validação de tipos e valores no lado do servidor. Você pode proibir a gravação se o preço for negativo ou o nome estiver vazio. Todas as verificações são realizadas no servidor do Google antes da gravação — isso garante a consistência dos dados independentemente do cliente (Android, iOS, Web, Admin SDK). As regras não protegem contra Admin SDK malicioso — ele ignora as regras por design. Para proteção completa, use Transaction Functions e Firebase Extensions.