Firebase Firestore — cos'è, documenti e collezioni NoSQL

Cos'è Firebase Firestore

Firebase Firestore è un database NoSQL cloud lanciato da Google nel 2019 come successore di Realtime Database. Firestore è costruito sull'infrastruttura di Google Cloud Spanner e Google Cloud Datastore, fornendo una forte coerenza dei dati all'interno di una singola transazione e replica multiregionale automatica. L'SDK supporta Android, iOS, Web (JavaScript), Flutter, Kotlin Multiplatform e Unity.

Evoluzione da Realtime Database

Firestore è stato annunciato al Google I/O 2017 come “Cloud Firestore” — una soluzione che affronta i principali limiti di Realtime Database: mancanza di supporto per query complesse, incapacità di scalare i dati su più nodi e coerenza debole. Secondo Google (2026), Firestore elabora oltre 1 trilione di richieste al giorno ed è il database predefinito per l'80% dei nuovi progetti Firebase. Tuttavia, Realtime Database rimane rilevante per scenari a latenza ultra-bassa (giochi, editing collaborativo) grazie alla sua struttura JSON semplice.

Limiti gratuiti di Firestore

Firestore è offerto con un modello pay-as-you-go con un generoso limite gratuito nel piano Spark: 1 GB di archiviazione, 10 GB di traffico di rete al mese, 50 mila operazioni di lettura, 20 mila operazioni di scrittura e 20 mila operazioni di eliminazione al giorno. Nel piano Blaze, tutto quanto sopra è gratuito e gli eccessi vengono addebitati: $0.06 per 100 mila operazioni di lettura, $0.18 per 100 mila operazioni di scrittura. Secondo Google (2026), il 90% dei progetti rimane entro il limite gratuito.

Modello dati: collezioni, documenti e campi

Il modello dati di Firestore è organizzato gerarchicamente: la radice contiene collezioni, ogni collezione contiene documenti, ogni documento contiene campi (tipi primitivi, array, Map) e collezioni annidate (sottocollezioni). La profondità di annidamento delle collezioni è illimitata, ma un documento non può contenere direttamente un altro documento — solo tramite un riferimento (tipo Reference).

Collezioni e documenti

Una collezione è un contenitore di documenti con identificatori generati automaticamente o definiti dall'utente. Ogni documento è un oggetto simile a JSON di dimensioni fino a 1 MiB. I campi del documento possono essere stringhe, numeri, valori booleani, array, Map, timestamp (Timestamp), punti geografici (GeoPoint) e riferimenti ad altri documenti (Reference). La dimensione del documento è limitata a 1 MiB, inclusi tutti i nomi dei campi.

Scrittura in batch e transazioni

Firestore supporta transazioni atomiche a livello di database. Una transazione può leggere e scrivere più documenti — Commit applica atomicamente tutte le modifiche o nessuna. Massimo 500 operazioni per transazione, timeout di 60 secondi. La scrittura in batch (batch write) è un'operazione di scrittura atomica non transazionale senza fase di lettura. Le transazioni sono fondamentali per operazioni finanziarie, prenotazioni di posti e gestione inventario.

Confronto tra Firestore e Realtime Database

Scegliere tra Firestore e Realtime Database dipende dai requisiti del progetto. Entrambi i database fanno parte dell'ecosistema Firebase, forniscono sincronizzazione in tempo reale e sono disponibili su tutte le piattaforme, ma differiscono fondamentalmente per modello dati, scalabilità e prezzi.

Differenze principali

Realtime Database memorizza i dati in un unico albero JSON, comodo per strutture semplici ma che rende difficile la scalabilità con annidamenti superiori a 3 livelli. Firestore utilizza un modello collezione-documento con sharding automatico, consentendo di scalare a milioni di documenti senza degrado delle prestazioni. Secondo Google (2026), Firestore supporta fino a 10 mila connessioni simultanee a una singola collezione senza perdita di velocità, mentre Realtime Database supporta fino a 200 mila connessioni a una singola istanza.

Prezzi

Realtime Database viene fatturato in base al volume di dati trasferiti (byte scaricati) e al numero di connessioni simultanee. Firestore viene fatturato in base al numero di operazioni (lettura, scrittura, eliminazione). Per applicazioni con aggiornamenti piccoli e frequenti (chat, notifiche), Firestore è generalmente più conveniente — ogni operazione di scrittura ha un prezzo fisso indipendentemente dalla dimensione dei dati. Per applicazioni con letture poco frequenti di grandi volumi di dati, Realtime Database potrebbe essere più economico.

Raccomandazione di Google (2026): utilizza Firestore come database predefinito per i nuovi progetti e Realtime Database per giochi e applicazioni dove la latenza minima (inferiore a 50 ms) e una struttura dati piatta sono critiche. Entrambi i database possono funzionare contemporaneamente nello stesso progetto.

Query, indici e paginazione in Firestore

Le query di Firestore vengono eseguite su collezioni o gruppi di collezioni con filtraggio, ordinamento e limiti. A differenza di Realtime Database, dove ogni query attraversa l'intero albero JSON con filtraggio lato client, Firestore esegue tutte le query sul server utilizzando indici pre-creati. Questo garantisce che la complessità della query dipenda solo dalla dimensione del risultato, non dalla dimensione della collezione.

Tipi di query

Firestore supporta il filtraggio per uno o più campi (uguaglianza, intervallo, in, array-contains, array-contains-any), ordinamento crescente e decrescente, limiti e cursori per la paginazione. Limitazioni: le query composte con filtraggio su campi diversi (WHERE price > 10 AND WHERE category == “books”) richiedono un indice composto; le query OR sono vietate (usa in e array-contains-any) e le query di disuguaglianza su campi diversi non sono consentite.

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)
}

Indici automatici e composti

Firestore crea automaticamente indici per campi singoli — le query su campo singolo funzionano senza alcuna configurazione. Per query con due o più campi (filtraggio + ordinamento), sono necessari indici composti. Al primo invio di una query, Firestore restituisce un errore con un link alla console dove l'indice può essere creato con un clic. Massimo 200 indici composti per database. Gli indici possono essere esportati e importati tramite Firebase CLI.

Integrazione di Firestore in Android

Connettere Firestore a un'app Android avviene in modo standard tramite Firebase BOM. Dopo aver aggiunto la dipendenza firebase-firestore-ktx, l'oggetto FirebaseFirestore è disponibile tramite getInstance() — senza chiavi o token aggiuntivi. Firestore utilizza lo stesso progetto Firebase degli altri servizi.

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

// Inizializzazione
val db = FirebaseFirestore.getInstance()

Lettura e scrittura dei dati

Firestore fornisce due modalità di lettura: una tantum (get) e in tempo reale (addSnapshotListener). La lettura una tantum recupera un documento una volta — utile per impostazioni e configurazione. Un listener si iscrive alle modifiche — qualsiasi aggiornamento del documento consegna automaticamente i dati aggiornati a tutti i client connessi in tempo reale. set() crea o sovrascrive un documento, update() modifica solo i campi specificati senza sovrascrivere l'intero documento.

Secondo Google (2026), le applicazioni di medie dimensioni (100 mila DAU) con Firestore in tempo reale consumano circa 5-10 GB di traffico in uscita al mese. L'uso della cache offline (Persistence Cache) riduce i download ripetuti del 60-70%, poiché l'SDK carica solo i documenti modificati al ripristino della connessione.

Modalità offline

Persistence Cache è un meccanismo integrato di Firestore per lavorare senza accesso a Internet. L'SDK memorizza automaticamente nella cache tutti i documenti letti sul dispositivo (fino a 500 MiB su Android). Quando la connessione viene persa, le letture continuano dalla cache e le scritture vengono accodate. Quando la connessione viene ripristinata, tutte le operazioni in sospeso vengono inviate al server e la cache viene sincronizzata con il server. Per il controllo dei conflitti, utilizza snapshot-metadata.hasPendingWrites e setOptions(ServerTimestampBehavior).

Regole di sicurezza e validazione dei dati

Security Rules è un linguaggio dichiarativo di controllo degli accessi per Firestore che viene eseguito sul server di Google prima di ogni operazione di lettura o scrittura. Le regole non richiedono codice lato server — vengono scritte nella console Firebase o tramite Firebase CLI e versionate tramite Git. Ogni operazione viene verificata rispetto alle regole e una violazione restituisce un errore PERMISSION_DENIED.

Struttura delle regole

Le Firestore Security Rules sono costituite da blocchi match ed espressioni allow. match definisce il percorso verso una collezione o un documento, allow specifica le operazioni consentite (read, write, create, update, delete) e una condizione — un'espressione simile a JavaScript che restituisce un booleano. Le regole possono verificare l'autenticazione (request.auth), i dati della richiesta (request.resource.data), i dati esistenti (resource.data), l'ora (request.time) e il percorso (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;
    }
  }
}

Validazione dei dati

Le Security Rules supportano la validazione di tipi e valori lato server. Puoi vietare la scrittura se il prezzo è negativo o il nome è vuoto. Tutti i controlli vengono eseguiti sul server di Google prima della scrittura — questo garantisce la coerenza dei dati indipendentemente dal client (Android, iOS, Web, Admin SDK). Le regole non proteggono da Admin SDK malintenzionato — bypassa le regole per progettazione. Per una protezione completa, utilizza Transaction Functions e Firebase Extensions.