Firebase Firestore — was es ist, NoSQL-Dokumente und Sammlungen

Was ist Firebase Firestore

Firebase Firestore ist eine Cloud-NoSQL-Datenbank, die von Google 2019 als Nachfolger der Realtime Database eingeführt wurde. Firestore basiert auf der Infrastruktur von Google Cloud Spanner und Google Cloud Datastore und bietet starke Datenkonsistenz innerhalb einer einzelnen Transaktion sowie automatische multiregionale Replikation. Das SDK unterstützt Android, iOS, Web (JavaScript), Flutter, Kotlin Multiplatform und Unity.

Entwicklung von der Realtime Database

Firestore wurde auf der Google I/O 2017 als „Cloud Firestore“ angekündigt — eine Lösung, die die wichtigsten Einschränkungen der Realtime Database behebt: fehlende Unterstützung für komplexe Abfragen, Unfähigkeit zur Datenskalierung über mehrere Knoten und schwache Konsistenz. Laut Google (2026) verarbeitet Firestore über 1 Billion Anfragen pro Tag und ist die Standarddatenbank für 80 % der neuen Firebase-Projekte. Die Realtime Database bleibt jedoch aufgrund ihrer einfachen JSON-Struktur für Szenarien mit extrem niedriger Latenz (Spiele, kollaboratives Bearbeiten) relevant.

Firestore kostenlose Grenzen

Firestore wird nach einem Pay-as-you-go-Modell mit einer großzügigen kostenlosen Grenze im Spark-Tarif angeboten: 1 GB Speicher, 10 GB Netzwerkverkehr pro Monat, 50.000 Leseoperationen, 20.000 Schreiboperationen und 20.000 Löschoperationen pro Tag. Im Blaze-Tarif ist alles oben Genannte kostenlos, und Überschreitungen werden berechnet: 0,06 $ pro 100.000 Leseoperationen, 0,18 $ pro 100.000 Schreiboperationen. Laut Google (2026) bleiben 90 % der Projekte innerhalb der kostenlosen Grenze.

Datenmodell: Sammlungen, Dokumente und Felder

Das Datenmodell von Firestore ist hierarchisch organisiert: Die Wurzel enthält Sammlungen, jede Sammlung enthält Dokumente, jedes Dokument enthält Felder (primitive Typen, Arrays, Map) und verschachtelte Sammlungen (Unterkollektionen). Die Verschachtelungstiefe der Sammlungen ist unbegrenzt, aber ein Dokument kann nicht direkt ein anderes Dokument enthalten — nur über eine Referenz (Reference-Typ).

Sammlungen und Dokumente

Eine Sammlung ist ein Container für Dokumente mit automatisch generierten oder benutzerdefinierten Identifikatoren. Jedes Dokument ist ein JSON-ähnliches Objekt mit einer Größe von bis zu 1 MiB. Dokumentfelder können Zeichenfolgen, Zahlen, boolesche Werte, Arrays, Map, Zeitstempel (Timestamp), Geopunkte (GeoPoint) und Verweise auf andere Dokumente (Reference) sein. Die Dokumentgröße ist auf 1 MiB einschließlich aller Feldnamen begrenzt.

Stapelschreiben und Transaktionen

Firestore unterstützt atomare Transaktionen auf Datenbankebene. Eine Transaktion kann mehrere Dokumente lesen und schreiben — Commit wendet entweder alle Änderungen atomar an oder gar keine. Maximal 500 Operationen pro Transaktion, Zeitüberschreitung 60 Sekunden. Ein Stapelschreiben (Batch Write) ist eine nicht-transaktionale atomare Schreiboperation ohne Lesephase. Transaktionen sind für Finanztransaktionen, Sitzplatzreservierungen und Bestandsverwaltung von entscheidender Bedeutung.

Vergleich von Firestore und Realtime Database

Die Wahl zwischen Firestore und Realtime Database hängt von den Projektanforderungen ab. Beide Datenbanken sind Teil des Firebase-Ökosystems, bieten Echtzeitsynchronisation und sind auf allen Plattformen verfügbar, unterscheiden sich jedoch grundlegend in Datenmodell, Skalierung und Preisgestaltung.

Hauptunterschiede

Die Realtime Database speichert Daten in einem einzigen JSON-Baum, was für einfache Strukturen praktisch ist, aber die Skalierung bei Verschachtelungen tiefer als 3 Ebenen erschwert. Firestore verwendet ein Sammlungs-Dokumenten-Modell mit automatischem Sharding, das eine Skalierung auf Millionen von Dokumenten ohne Leistungseinbußen ermöglicht. Laut Google (2026) unterstützt Firestore bis zu 10.000 gleichzeitige Verbindungen zu einer einzelnen Sammlung ohne Geschwindigkeitsverlust, während die Realtime Database bis zu 200.000 Verbindungen zu einer einzelnen Instanz unterstützt.

Preisgestaltung

Die Realtime Database wird basierend auf der übertragenen Datenmenge (heruntergeladene Bytes) und der Anzahl gleichzeitiger Verbindungen abgerechnet. Firestore wird nach der Anzahl der Operationen (Lesen, Schreiben, Löschen) abgerechnet. Für Anwendungen mit häufigen kleinen Aktualisierungen (Chat, Benachrichtigungen) ist Firestore in der Regel kostengünstiger — jede Schreiboperation hat einen festen Preis, unabhängig von der Datengröße. Für Anwendungen mit seltenen Lesezugriffen auf große Datenmengen kann die Realtime Database günstiger sein.

Empfehlung von Google (2026): Verwenden Sie Firestore als Standarddatenbank für neue Projekte und die Realtime Database für Spiele und Anwendungen, bei denen minimale Latenz (unter 50 ms) und eine flache Datenstruktur entscheidend sind. Beide Datenbanken können gleichzeitig im selben Projekt arbeiten.

Abfragen, Indizes und Paginierung in Firestore

Firestore-Abfragen werden gegen Sammlungen oder Sammlungsgruppen mit Filterung, Sortierung und Grenzen ausgeführt. Im Gegensatz zur Realtime Database, bei der jede Abfrage den gesamten JSON-Baum mit clientseitiger Filterung durchläuft, führt Firestore alle Abfragen auf dem Server unter Verwendung vorab erstellter Indizes aus. Dies garantiert, dass die Abfragekomplexität nur von der Ergebnisgröße und nicht von der Sammlungsgröße abhängt.

Abfragearten

Firestore unterstützt die Filterung nach einem oder mehreren Feldern (Gleichheit, Bereich, in, array-contains, array-contains-any), aufsteigende und absteigende Sortierung, Grenzen und Cursor für die Paginierung. Einschränkungen: Zusammengesetzte Abfragen mit Filterung nach verschiedenen Feldern (where price > 10 AND where category == „books“) erfordern einen zusammengesetzten Index; OR-Abfragen sind verboten (verwenden Sie stattdessen in und array-contains-any), und Ungleichheitsabfragen über verschiedene Felder sind nicht zulässig.

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 und zusammengesetzte Indizes

Firestore erstellt automatisch Indizes für einzelne Felder — Einzelfeldabfragen funktionieren ohne Konfiguration. Für Abfragen mit zwei oder mehr Feldern (Filterung + Sortierung) sind zusammengesetzte Indizes erforderlich. Beim ersten Senden einer Abfrage gibt Firestore einen Fehler mit einem Link zur Konsole zurück, wo der Index mit einem Klick erstellt werden kann. Maximal 200 zusammengesetzte Indizes pro Datenbank. Indizes können über die Firebase CLI exportiert und importiert werden.

Integration von Firestore in Android

Firestore mit einer Android-App verbinden erfolgt standardmäßig über Firebase BOM. Nach dem Hinzufügen der Abhängigkeit firebase-firestore-ktx ist das FirebaseFirestore-Objekt über getInstance() verfügbar — ohne zusätzliche Schlüssel oder Tokens. Firestore verwendet dasselbe Firebase-Projekt wie die anderen Dienste.

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

// Initialisierung
val db = FirebaseFirestore.getInstance()

Daten lesen und schreiben

Firestore bietet zwei Lesemodi: einmalig (get) und in Echtzeit (addSnapshotListener). Einmaliges Lesen ruft ein Dokument einmal ab — nützlich für Einstellungen und Konfigurationen. Ein Listener abonniert Änderungen — jede Dokumentaktualisierung liefert automatisch aktualisierte Daten an alle verbundenen Clients in Echtzeit. set() erstellt oder überschreibt ein Dokument, update() ändert nur die angegebenen Felder, ohne das gesamte Dokument zu überschreiben.

Laut Google (2026) verbrauchen mittelgroße Anwendungen (100.000 DAU) mit Echtzeit-Firestore etwa 5-10 GB ausgehenden Datenverkehr pro Monat. Die Verwendung des Offline-Cache (Persistence Cache) reduziert wiederholte Downloads um 60-70 %, da das SDK bei Wiederherstellung der Verbindung nur geänderte Dokumente lädt.

Offline-Modus

Persistence Cache ist ein integrierter Firestore-Mechanismus für die Arbeit ohne Internetzugang. Das SDK speichert automatisch alle gelesenen Dokumente auf dem Gerät zwischen (bis zu 500 MiB auf Android). Bei Verbindungsverlust werden Lesevorgänge aus dem Cache fortgesetzt und Schreibvorgänge in die Warteschlange gestellt. Bei Wiederherstellung der Verbindung werden alle ausstehenden Operationen an den Server gesendet und der Cache mit dem Server synchronisiert. Zur Konfliktkontrolle verwenden Sie snapshot-metadata.hasPendingWrites und setOptions(ServerTimestampBehavior).

Sicherheitsregeln und Datenvalidierung

Security Rules ist eine deklarative Zugriffskontrollsprache für Firestore, die vor jedem Lese- oder Schreibvorgang auf dem Google-Server ausgeführt wird. Regeln erfordern keinen serverseitigen Code — sie werden in der Firebase-Konsole oder über die Firebase CLI geschrieben und über Git versioniert. Jeder Vorgang wird gegen die Regeln geprüft, und ein Verstoß gibt einen PERMISSION_DENIED-Fehler zurück.

Struktur der Regeln

Firestore Security Rules bestehen aus match-Blöcken und allow-Ausdrücken. match definiert den Pfad zu einer Sammlung oder einem Dokument, allow gibt die erlaubten Operationen (read, write, create, update, delete) und eine Bedingung an — einen JavaScript-ähnlichen Ausdruck, der einen booleschen Wert zurückgibt. Regeln können Authentifizierung (request.auth), Anforderungsdaten (request.resource.data), vorhandene Daten (resource.data), Zeit (request.time) und Pfad (request.path) überprüfen.

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

Datenvalidierung

Security Rules unterstützen die Typ- und Wertvalidierung auf der Serverseite. Sie können das Schreiben verbieten, wenn der Preis negativ oder der Name leer ist. Alle Prüfungen werden vor dem Schreiben auf dem Google-Server durchgeführt — dies gewährleistet Datenkonsistenz unabhängig vom Client (Android, iOS, Web, Admin SDK). Regeln schützen nicht vor böswilligem Admin SDK — es umgeht die Regeln von Natur aus. Für vollständigen Schutz verwenden Sie Transaction Functions und Firebase Extensions.