Firebase Firestore — wat is het, documenten en NoSQL-collecties

Wat is Firebase Firestore

Firebase Firestore is een cloud NoSQL-database die in 2019 door Google is gelanceerd als opvolger van Realtime Database. Firestore is gebouwd op de infrastructuur van Google Cloud Spanner en Google Cloud Datastore en biedt strikte gegevensconsistentie binnen één transactie en automatische multi-regionale replicatie. SDK ondersteunt Android, iOS, Web (JavaScript), Flutter, Kotlin Multiplatform en Unity.

Evolutie van Realtime Database

Firestore werd aangekondigd op Google I/O 2017 als „Cloud Firestore” — een oplossing die de belangrijkste beperkingen van Realtime Database wegneemt: gebrek aan ondersteuning voor complexe query's, onmogelijkheid om gegevens over meerdere nodes te schalen en zwakke consistentie. Volgens gegevens van Google (2026) verwerkt Firestore meer dan 1 biljoen query's per dag en is het de standaarddatabase voor 80% van de nieuwe Firebase-projecten. Realtime Database blijft echter relevant voor scenario's met ultra-lage latentie (games, gezamenlijk bewerken) dankzij de eenvoudige JSON-structuur.

Gratis limieten van Firestore

Firestore wordt aangeboden volgens het pay-as-you-go-model met een royale gratis limiet op het Spark-tarief: 1 GB opslag, 10 GB netwerkverkeer per maand, 50 duizend leesbewerkingen, 20 duizend schrijfbewerkingen en 20 duizend verwijderingen per dag. Op het Blaze-tarief is alles hetzelfde gratis, en overschrijdingen worden getarifeerd: $0.06 per 100 duizend leesbewerkingen, $0.18 per 100 duizend schrijfbewerkingen. Volgens gegevens van Google (2026) blijft 90% van de projecten binnen de gratis limiet.

Gegevensmodel: collecties, documenten en velden

Het gegevensmodel van Firestore is hiërarchisch georganiseerd: de root bevat collecties, elke collectie bevat documenten, elk document bevat velden (primitieve types, arrays, Map) en geneste collecties (subcollections). De diepte van nesting van collecties is niet beperkt, maar een document kan niet direct een ander document bevatten — alleen via een referentie (Reference type).

Collecties en documenten

Een collectie is een container voor documenten met automatisch gegenereerde of opgegeven identificaties. Elk document is een JSON-achtig object met een grootte tot 1 MiB. Velden van een document kunnen strings, getallen, Booleaanse waarden, arrays, Map, tijdstempels (Timestamp), geografische punten (GeoPoint) en verwijzingen naar andere documenten (Reference) zijn. De documentgrootte is beperkt tot 1 MiB, inclusief de namen van alle velden.

Batchschrijven en transacties

Firestore ondersteunt atomaire transacties op databaseniveau. Een transactie kan meerdere documenten lezen en schrijven — Commit past alle wijzigingen atomair toe of geen enkele. Maximaal 500 bewerkingen per transactie, time-out 60 seconden. Batchschrijven (batch write) is een niet-transactionele atomaire schrijfbewerking zonder leesfase. Transacties zijn cruciaal voor financiële operaties, reserveringen en inventarisatie.

Vergelijking van Firestore en Realtime Database

De keuze tussen Firestore en Realtime Database hangt af van de projectvereisten. Beide databases maken deel uit van het Firebase-ecosysteem, bieden real-time synchronisatie en zijn beschikbaar op alle platforms, maar verschillen fundamenteel in gegevensmodel, schaalbaarheid en prijsstelling.

Belangrijkste verschillen

Realtime Database slaat gegevens op in één JSON-boom, wat handig is voor eenvoudige structuren, maar schalen bemoeilijkt bij nesting dieper dan 3 niveaus. Firestore gebruikt het collectie-documentmodel met automatische sharding, wat schalen tot miljoenen documenten mogelijk maakt zonder prestatieverlies. Volgens gegevens van Google (2026) ondersteunt Firestore tot 10 duizend gelijktijdige verbindingen met één collectie zonder snelheidsverlies, Realtime Database — tot 200 duizend verbindingen met één instantie.

Prijsstelling

Realtime Database wordt getarifeerd op basis van het volume overgedragen gegevens (gedownloade bytes) en het aantal gelijktijdige verbindingen. Firestore — op basis van het aantal bewerkingen (lezen, schrijven, verwijderen). Voor applicaties met frequente kleine updates (chat, meldingen) is Firestore meestal voordeliger — elke schrijfbewerking heeft een vaste prijs ongeacht de gegevensgrootte. Voor applicaties met zeldzame lezingen van grote hoeveelheden gegevens kan Realtime Database goedkoper zijn.

Aanbeveling van Google (2026): gebruik Firestore als standaarddatabase voor nieuwe projecten, en Realtime Database — voor games en applicaties waar minimale latentie (minder dan 50 ms) cruciaal is en de gegevensstructuur plat is. Beide databases kunnen gelijktijdig in één project werken.

Query's, indexen en paginering in Firestore

Firestore-query's worden uitgevoerd op collecties of groepen collecties met filtering, sortering en limiet. In tegenstelling tot Realtime Database, waar elke query een doorloop van de hele JSON-boom is met een filter aan de clientzijde, voert Firestore alle query's op de server uit met behulp van vooraf gemaakte indexen. Dit garandeert dat de complexiteit van een query alleen afhangt van de grootte van het resultaat, niet van de grootte van de collectie.

Soorten query's

Firestore ondersteunt filtering op één of meerdere velden (equality, range, in, array-contains, array-contains-any), oplopend en aflopend sorteren, limiet en cursors voor paginering. Beperkingen: samengestelde query's met filtering op verschillende velden (where price > 10 AND where category == „books”) vereisen een samengestelde index; OR-query's zijn verboden (in en array-contains-any worden gebruikt) en query's met ongelijkheid op verschillende velden zijn verboden.

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

Automatische en samengestelde indexen

Firestore maakt automatisch indexen voor afzonderlijke velden — query's op één veld werken zonder enige configuratie. Voor query's met twee of meer velden (filteren + sorteren) worden samengestelde indexen gemaakt. Bij de eerste verzending van een query retourneert Firestore een fout met een link naar de console, waar de index met één klik kan worden aangemaakt. Maximaal 200 samengestelde indexen per database. Indexen kunnen worden geëxporteerd en geïmporteerd via firebase CLI.

Firestore integreren in Android

Firestore aansluiten op een Android-applicatie gebeurt standaard via Firebase BOM. Na het toevoegen van de afhankelijkheid firebase-firestore-ktx is het FirebaseFirestore-object beschikbaar via getInstance() — zonder extra sleutels of tokens. Firestore gebruikt hetzelfde Firebase-project als de andere services.

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

// Initialisatie
val db = FirebaseFirestore.getInstance()

Gegevens lezen en schrijven

Firestore biedt twee leesmodi: eenmalig (get) en in real-time (addSnapshotListener). Eenmalig lezen haalt het document één keer op — handig voor instellingen en configuratie. De listener abonneert zich op wijzigingen — elke update van een document levert automatisch bijgewerkte gegevens aan alle verbonden clients in real-time. set() maakt of overschrijft een document, update() wijzigt alleen de opgegeven velden zonder het hele document te overschrijven.

Volgens gegevens van Google (2026) verbruiken middelgrote applicaties (100 duizend DAU) met Firestore in real-time ongeveer 5-10 GB aan uitgaand verkeer per maand. Gebruik van offline cache (Persistence Cache) vermindert het volume aan herhaalde downloads met 60-70%, omdat SDK alleen gewijzigde documenten downloadt bij herstel van de verbinding.

Offline modus

Persistence Cache is een ingebouwd mechanisme van Firestore om zonder internet te werken. SDK cachet automatisch alle gelezen documenten op het apparaat (tot 500 MiB op Android). Bij verlies van verbinding wordt lezen uit de cache voortgezet, schrijven wordt in de wachtrij geplaatst. Bij herstel van de verbinding worden alle uitgestelde bewerkingen naar de server verzonden en wordt de cache met de server gesynchroniseerd. Voor conflictbeheersing worden snapshot-metadata.hasPendingWrites en setOptions(ServerTimestampBehavior) gebruikt.

Beveiligingsregels en gegevensvalidatie

Security Rules is een declaratieve taal voor toegangsbeperking tot Firestore, die op de Google-server wordt uitgevoerd vóór elke lees- of schrijfbewerking. Rules hebben geen servercode nodig — ze worden geschreven in de Firebase-console of via firebase CLI en worden via Git versiebeheerd. Elke bewerking wordt gecontroleerd op naleving van de regels, en bij overtreding wordt een PERMISSION_DENIED-fout geretourneerd.

Structuur van regels

De regels van Firestore Security Rules bestaan uit match-blokken en allow-expressies. match definieert het pad naar de collectie of het document, allow specificeert de toegestane bewerkingen (read, write, create, update, delete) en de voorwaarde — een JavaScript-achtige expressie die een Booleaanse waarde retourneert. De regels kunnen authenticatie (request.auth), aanvraaggegevens (request.resource.data), bestaande gegevens (resource.data), tijd (request.time) en pad (request.path) controleren.

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

Gegevensvalidatie

Security Rules ondersteunen validatie van types en waarden aan de serverzijde. Schrijven kan worden verboden als de prijs negatief is of de naam leeg is. Alle controles worden op de Google-server uitgevoerd vóór het schrijven — dit garandeert gegevensconsistentie ongeacht de client (Android, iOS, Web, Admin SDK). Rules beschermen niet tegen kwaadwillende Admin SDK — deze omzeilt per definitie de regels. Gebruik voor volledige bescherming Transaction Functions en Firebase Extensions.