Firebase Realtime Database: Was es ist, JSON-Struktur und Synchronisation

Was ist Firebase Realtime Database

Firebase Realtime Database ist eine der ersten Cloud-Echtzeitdatenbanken, die von Google zusammen mit Firebase im Jahr 2012 gestartet wurde. Es ist eine NoSQL-Datenbank, in der Daten als einzelner JSON-Baum gespeichert werden, der über eine einzige URL zugänglich ist. Client-SDKs (Android, iOS, Web) abonnieren bestimmte Baumknoten über WebSocket und erhalten bei jeder Datenänderung Updates — ohne Server-Polling und ohne Implementierung eines eigenen Push-Mechanismus.

Geschichte und Entwicklung

Das ursprüngliche Firebase wurde 2011 von James Tamplin und Andrew Lee gegründet, und das erste Produkt war die Realtime Database selbst. Nach der Übernahme durch Google im Jahr 2014 (laut TechCrunch — für einen Betrag zwischen 50 und 100 Millionen Dollar) wurde die Datenbank in Google Cloud integriert und erhielt einen deutlich höheren Durchsatz. Im Jahr 2017 kündigte Google Firestore als evolutionären Ersatz an, aber Realtime Database wird weiterhin aktiv unterstützt und aktualisiert. Laut Google (2026) wird Realtime Database immer noch in mehr als 1,5 Millionen aktiven Projekten verwendet.

Kostenlose Limits und Preise

Spark-Tarif (kostenlos) beinhaltet: 1 GB Speicher, 10 GB heruntergeladene Daten pro Monat, 100 gleichzeitige Verbindungen und Datenbankunterstützung in einer Region. Im Blaze-Tarif (Pay-as-you-go) wird für zusätzlichen Speicher ($1/GB), Traffic ($0,12/GB) und gleichzeitige Verbindungen ($5 pro 100.000 über dem Limit) berechnet. Für Tests steht auch ein Emulationsmodus zur Verfügung — firebase emulators:start — der Realtime Database lokal ohne Cloud-Verbindung ausführt.

Datenstruktur: JSON-Baum und Normalisierung

Realtime Database hat keine Tabellen, Sammlungen oder Dokumente — alles ist ein einzelner JSON-Baum, der über eine URL wie https://project-name-default-rtdb.firebaseio.com/ zugänglich ist. Jeder Schlüssel im Baum ist entweder ein Endwert (String, Zahl, Boolean, null) oder ein verschachtelter Knoten mit untergeordneten Schlüsseln. Die Datenbank-Engine unterstützt keine JOINs, Unterabfragen oder Aggregationen — eine Abfrage gibt immer den Inhalt eines Knotens mit allen untergeordneten Elementen zurück.

Datenormalisierung

Aufgrund fehlender JOINs in Realtime Database ist die Datenormalisierung obligatorisch. Statt eines verschachtelten Baums (Benutzer → Liste seiner Beiträge) werden Daten in flache Listen mit Referenzen über Schlüssel aufgeteilt. Dies ist der Standardansatz: Daten werden denormalisiert, damit das Lesen eines Knotens nicht den gesamten Kontext mitzieht. Beispielsweise wird die Liste der Chat-Nachrichten getrennt von Benutzerprofilen gespeichert, und jeder Beitrag enthält nur die ID des Autors, nicht dessen gesamtes Profil.

Abfragen in Realtime Database

Abfragen in Realtime Database werden mit Filtern (orderByChild, orderByKey, orderByValue, limitToFirst, limitToLast, equalTo, startAt, endAt) ausgeführt. Anders als Firestore werden Indizes manuell über den Abschnitt Rules (.indexOn) erstellt. Wenn ein Index nicht deklariert ist, gibt eine Abfrage mit Sortierung einen PERMISSION_DENIED-Fehler zurück. Abfragen funktionieren nur auf einem einzigen Feld — zusammengesetzte Abfragen (Filtern nach Preis + Sortieren nach Datum) werden nicht unterstützt. Für komplexe Filterung werden Daten oft in verschiedenen Knoten mit unterschiedlichen Sortierschlüsseln dupliziert.

Realtime Database vs Firestore: Was wählen

Die Wahl zwischen Realtime Database und Firestore ist eine der häufigen Architekturentscheidungen beim Start eines Projekts. Google empfiehlt Firestore für die meisten neuen Anwendungen, aber Realtime Database bleibt die beste Wahl für Szenarien, in denen eine minimale Datenübertragungslatenz kritisch ist.

Drei Schlüsselszenarien für Realtime Database

Erstes Szenario — Multiplayer-Spiele mit Zustandssynchronisation (Schach, Kartenspiele, Echtzeit-Action). Die Latenz von Realtime Database beträgt 10-30 ms gegenüber 50-100 ms bei Firestore in derselben Region. Zweites Szenario — Chats und Messenger mit hoher Nachrichtenfrequenz. Realtime Database wird nach Datenvolumen abgerechnet, nicht nach Anzahl der Schreibvorgänge, was es bei Frequenzen über 1 Nachricht pro Sekunde deutlich günstiger macht als Firestore. Drittes Szenario — Benutzerpräsenz (online/offline), wo die onDisconnect-Handler von Realtime Database das atomare Setzen des Status bei Verbindungsabbruch ermöglichen.

Laut Google (2026) entscheiden sich etwa 15 % der neuen Firebase-Projekte bewusst für Realtime Database — wenn das Team seine Anforderungen an Latenz, Datenstruktur und Budget genau versteht. In den restlichen 85 % der Fälle ist Firestore aufgrund seiner besseren Skalierbarkeit, leistungsfähigeren Abfragen und automatischen Replikation die sicherere Wahl.

Integration von Realtime Database in Android

Verbinden von Realtime Database mit einer Android-Anwendung erfolgt durch Hinzufügen der Abhängigkeit firebase-database-ktx in build.gradle. Das FirebaseDatabase-Objekt ist über getInstance(url) verfügbar — Sie können mehrere Datenbanken innerhalb eines Firebase-Projekts verbinden. Nach der Initialisierung stellt das SDK automatisch eine WebSocket-Verbindung zum Server her und beginnt mit der Datensynchronisation.

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

// Initialization with custom URL
val database = FirebaseDatabase.getInstance(
    "https://my-project-default-rtdb.firebaseio.com/"
)
val ref = database.getReference("chats")

Schreiben und Lesen von Daten

Realtime Database verwendet das DatabaseReference-Objekt für alle Operationen. setValue() schreibt Daten in den angegebenen Knoten und ersetzt dessen gesamten Inhalt vollständig. push() generiert automatisch einen eindeutigen Schlüssel (basierend auf einem Zeitstempel) zum Hinzufügen eines Elements zu einer Liste — dies ist die Standardmethode zum Erstellen von Chat-Nachrichten, Beiträgen und Aufzeichnungen. updateChildren() ändert mehrere Knoten atomar in einem einzigen Vorgang. addValueEventListener abonniert Knotenänderungen und erhält bei jeder Datenaktualisierung einen Callback.

data class Message(
    val author: String = "",
    val text: String = "",
    val timestamp: Long = ServerValue.TIMESTAMP
)

class ChatRepository(private val ref: DatabaseReference) {
    fun sendMessage(author: String, text: String) {
        val msg = Message(author = author, text = text)
        ref.child("messages").push().setValue(msg)
    }

    fun observeMessages(): Flow<List<Message>> = callbackFlow {
        val listener = ref.child("messages")
            .addValueEventListener(object : ValueEventListener {
                override fun onDataChange(snapshot: DataSnapshot) {
                    val messages = snapshot.children.mapNotNull { it.getValue(Message::class.java) }
                    trySend(messages)
                }
                override fun onCancelled(error: DatabaseError) {}
            })
        awaitClose { ref.removeEventListener(listener) }
    }
}

Echtzeit-Synchronisation und Offline-Modus

Der Synchronisationsmechanismus von Realtime Database basiert auf dem WebSocket-Protokoll (zuvor — Long-Polling). Der Client sendet eine Anfrage zum Abonnieren eines bestimmten Knotens, und der Server hält die Verbindung offen. Bei jeder Datenänderung im abonnierten Knoten sendet der Server das vollständige JSON dieses Knotens an den Client. Das SDK auf dem Client aktualisiert automatisch den lokalen Zustand und löst die entsprechenden Callbacks (onDataChange) aus.

OnDisconnect — Verbindungsabbrüche

OnDisconnect ist eine einzigartige Funktion von Realtime Database, die in Firestore nicht vorhanden ist. Ein Entwickler kann einen Schreibvorgang registrieren, der auf dem Server automatisch ausgeführt wird, wenn die Verbindung des Clients getrennt wird. Dies wird für Präsenzstatus verwendet: „user123/status“: „online“ mit onDisconnect.setValue(„offline“). Wenn der Benutzer die App schließt oder das Internet verliert, setzt der Server automatisch den Status auf „offline“, und zwar innerhalb von maximal 3 Minuten (in der Firebase-Konsole konfigurierbar).

Offline-Cache

Persistence wird in Realtime Database mit einer einzigen Zeile aktiviert: FirebaseDatabase.getInstance().setPersistenceEnabled(true). Das SDK speichert den letzten Zustand aller abonnierten Knoten auf der Festplatte zwischen (standardmäßig bis zu 10 MiB, konfigurierbar bis zu 100 MiB). Bei Verbindungsverlust arbeitet der Client mit zwischengespeicherten Daten weiter, und alle Schreibvorgänge werden in eine Warteschlange gestellt. Wenn die Verbindung wiederhergestellt ist, sendet das SDK alle angesammelten Änderungen in der richtigen Reihenfolge (FIFO) an den Server.

Laut Google (2026) verlieren Anwendungen mit aktiviertem Persistenz-Cache bei Verbindungsabbruch 40 % seltener Benutzerdaten. Wenn ein Client jedoch mehr als 1000 ausstehende Vorgänge angesammelt hat, kann der Server sie alle ablehnen und eine vollständige Synchronisation anfordern — dies ist ein Schutzmechanismus gegen veraltete Clients.

Sicherheitsregeln und Validierung

Sicherheitsregeln in Realtime Database sind eine JSON-Konfiguration, die beschreibt, wer unter welchen Bedingungen Daten in jedem Knoten lesen und schreiben kann. Die Regeln werden auf Googles Servern ausgeführt und vor jeder Operation angewendet. Standardmäßig (in der Produktion) wird empfohlen, die Regeln in den Modus „geschlossen“ zu setzen — nur authentifizierte Benutzer haben Zugriff.

Struktur der Regeln

Realtime Database-Regeln werden im JSON-Format mit den Abschnitten .read, .write, .validate, .indexOn geschrieben. Anders als Firestore (das eine match-Syntax verwendet) verwendet Realtime Database verschachtelte Objekte, die die Datenstruktur widerspiegeln. Bedingungen prüfen auth (Authentifizierung), data (vorhandene Daten), newData (neue Daten beim Schreiben) und now (Serverzeit). Validierungsregeln (.validate) ermöglichen die Überprüfung von Typen, Wertebereichen und Datenstruktur.

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth.uid === $uid",
        ".write": "auth.uid === $uid",
        ".validate": "newData.hasChildren(['name', 'email'])"
      }
    },
    "messages": {
      ".indexOn": ["timestamp"],
      "$msgId": {
        ".read": true,
        ".write": "auth.uid !== null",
        ".validate": "newData.child('text').isString() && newData.child('text').val().length <= 500"
      }
    }
  }
}

Kaskadenverhalten und Testen von Regeln

Die Regeln von Realtime Database werden kaskadierend vererbt — wenn .read = false auf der obersten Ebene ist, sind alle untergeordneten Knoten unabhängig von ihren eigenen Regeln nicht lesbar. Firebase bietet einen Regelsimulator in der Konsole, in dem Sie Operationen mit verschiedenen Auth-Tokens vor dem Deployment testen können. Es wird empfohlen, Regeln immer im Simulator zu testen — ein Fehler in einer Regel kann den Zugriff auf private Daten aller Benutzer öffnen. Laut Google (2026) werden 40 % der Datenlecks in Firebase-Projekten durch falsch konfigurierte Sicherheitsregeln verursacht.