Was ist Firestore?

Cloud Firestore ist eine Datenbank, die es nur als Dienst gibt: Sie läuft in der Google Cloud, und eine Fassung zum Herunterladen und Selbstbetreiben existiert nicht. Gespeichert wird in Dokumenten und Sammlungen, ähnlich wie bei MongoDB, also ohne feste Spalten. Firestore gehört zu Firebase, Googles Baukasten für App-Entwicklung, der daneben Anmeldung, Benachrichtigungen und Dateispeicher mitbringt.

Der ungewöhnlichste Zug ist der Wegfall der Mitte. Klassisch redet eine App mit einem Server, und erst der Server redet mit der Datenbank. Bei Firestore verbindet sich die App direkt mit der Datenbank. Was ein Benutzer sehen und ändern darf, regelt kein eigener Servercode, sondern Sicherheitsregeln, die bei Google hinterlegt sind und dort bei jedem Zugriff ausgewertet werden. Für kleine Teams heißt das: eine Schicht weniger bauen, betreiben und bezahlen.

Die zweite Besonderheit ist die Echtzeit. Eine App fragt Daten nicht nur einmal ab, sie kann sie abonnieren. Ändert irgendjemand ein Dokument, schiebt Firestore die Änderung von selbst an alle Geräte, die gerade zuhören. Eine Auftragsliste, die sich auf dem Tablet der Disposition aktualisiert, sobald der Fahrer auf Start tippt, ist damit kein Sonderbau mehr, sondern der Normalfall.

Technisch bindet die App eine Bibliothek von Firebase ein und meldet sich für die Daten an, die sie braucht. Das Abonnieren sieht im Code so aus:

Dazu kommt der Offline-Betrieb. Die Bibliothek hält eine Kopie der zuletzt genutzten Daten auf dem Gerät. Fällt das Netz aus, liest und schreibt die App einfach weiter, und sobald wieder Verbindung besteht, gleicht Firestore die Änderungen ab. Für Außendienst, Lager oder Baustelle ist das der Punkt, der den Ausschlag gibt, denn Funklöcher sind dort Alltag und kein Ausnahmefall.

Abgerechnet wird kleinteilig: je Lesevorgang, je Schreibvorgang, je Löschvorgang, dazu Speicher und Datenverkehr. Ein kostenloses Kontingent deckt den Anfang ab. Dieses Modell prägt, wie man für Firestore baut. Eine Ansicht, die bei jedem Öffnen tausend Dokumente liest, ist nicht nur langsam, sie steht am Monatsende auf der Rechnung. Gute Firestore-Anwendungen laden wenig und gezielt.

Firestore ist zu Hause, wo mehrere Menschen gleichzeitig auf denselben Daten arbeiten und die App auch ohne Netz weiterlaufen soll. Typische Einsatzgebiete sind:

• Auftrags- und Tourenlisten für Fahrer, Monteure und Disposition, die auf allen Geräten denselben Stand zeigen
• Erfassungs-Apps für unterwegs, etwa Zählerstände, Prüfungen oder Unterschriften, mit Abgleich nach dem Funkloch
• Chats und Kommentarfunktionen, bei denen Nachrichten sofort beim Gegenüber erscheinen
• Statusanzeigen und Übersichten, etwa welcher Raum belegt oder welche Maschine frei ist
• Erste Fassungen neuer Produkte, die ohne eigenen Server schnell bei echten Nutzern landen sollen

Wir setzen Firestore genau in diesem Feld ein: Apps, oft mit React Native gebaut, in denen eine Änderung auf einem Gerät ohne Neuladen auf dem nächsten ankommt. Die Abrechnung oder das Berichtswesen daneben legen wir in eine relationale Datenbank, weil dort gerechnet wird. Diese Trennung hat sich bewährt: Firestore für das Live-Geschehen, klassische Datenbanken für das, was am Monatsende zusammengezählt wird.

Firestore ist das Ergebnis einer Übernahme. Firebase startete als eigenständiges Startup, dessen Realtime Database genau eine Sache konnte, die damals kaum jemand bot: Daten in Echtzeit auf viele Geräte verteilen. 2014 kaufte Google die Firma und baute Firebase zur breiten App-Plattform aus. Weil die Realtime Database bei größeren Datenmengen und Abfragen an Grenzen stieß, stellte Google 2017 Firestore als Nachfolger vor, mit besserem Datenmodell und Anschluss an die übrige Google Cloud.

Firestore nimmt euch den Server ab, aber es nimmt euch auch Möglichkeiten. Wer sich dafür entscheidet, sollte drei Dinge vorher wissen:

• Auswertungen sind nicht sein Fach: Abfragen über viele Dokumente hinweg sind eingeschränkt, und weil jede gelesene Zeile kostet, wird ein Monatsbericht teuer und umständlich
• Es läuft nur bei Google: Wenn eure Daten in einem deutschen Rechenzentrum oder im eigenen Haus liegen müssen, scheidet Firestore aus
• Die Bindung geht über die Datenbank hinaus: Anmeldung, Benachrichtigungen und Sicherheitsregeln von Firebase ziehen bei einem Wechsel nicht mit um
• Verknüpfte Daten mit Prüfregeln, etwa Kunde, Auftrag und Rechnung, sind in einer relationalen Datenbank besser aufgehoben

Deshalb bauen wir den Datenzugriff in Firestore-Projekten von Anfang an gebündelt an einer Stelle, statt Aufrufe über die ganze App zu verteilen. Ein späterer Wechsel bleibt dann Arbeit, aber er wird kein Neubau.

Hinter dieser Frage steckt eine grundsätzlichere: Wollt ihr einen Server betreiben oder nicht? Eine eigene Datenbank, etwa PostgreSQL auf einem gemieteten Server, gehört euch samt aller Freiheiten. Ihr bestimmt den Standort, zahlt einen festen Monatspreis und fragt ab, was ihr wollt. Dafür braucht sie jemanden, der Aktualisierungen einspielt, Sicherungen prüft und nachts zuständig ist, wenn etwas klemmt. Firestore dreht das um: kein Betrieb, keine Wartung, dafür Abrechnung nach Nutzung und Bindung an Google. Als Orientierung:

• App mit Echtzeit und Offline-Betrieb, kleines Team, kein eigener Serverbetrieb gewünscht: Firestore
• Verknüpfte Geschäftsdaten, Berichte, volle Kontrolle über den Speicherort: eigene Datenbank
• Planbare Kosten wichtiger als Bequemlichkeit: eigene Datenbank, denn ein Festpreis überrascht nicht
• Schneller Start eines Produkts, dessen Zukunft noch offen ist: Firestore, mit gebündeltem Datenzugriff als Ausstiegstür

Oft ist die Antwort keine Entweder-oder-Entscheidung. Bei einem Lieferdienst, dessen Fahrer-App wir gebaut haben, laufen Aufträge und Status in Echtzeit über Firestore, die Abrechnung am Monatsende dagegen in einer relationalen Datenbank. Jedes System macht das, wofür es gebaut ist.

Für Auftraggeber hat Firestore einen ungewohnten Kostenverlauf. Es gibt keinen Serverpreis, sondern eine Rechnung, die mit der Nutzung wächst: bei wenigen hundert Nutzern oft ein niedriger zweistelliger Betrag im Monat, bei ungeschickt gebauten Ansichten deutlich mehr. Seriös ist, wer von Anfang an ein Budget mit Warnung einrichtet und beim Bauen darauf achtet, was jede Ansicht liest. Fragt euren Dienstleister ruhig danach, die Antwort zeigt, ob er das Abrechnungsmodell verstanden hat.

Der zweite Punkt ist der Datenschutz. Firestore läuft bei Google, die Region lässt sich aber wählen, etwa Frankfurt oder Belgien, und für den Auftragsverarbeitungsvertrag liegen die Unterlagen von Google vor. Ob das für eure Daten reicht, hängt davon ab, wie heikel sie sind: Bei Gesundheits- oder Personaldaten raten wir eher zu einer Datenbank in Deutschland. Solche Fragen gehören in die IT-Sicherheitsberatung vor dem Projekt, nicht in die Woche vor dem Start. Was wir mit Firestore bauen und was bewusst nicht, steht auf unserer Firestore-Seite.

Für seinen Zweck: ja. Echtzeit-Abgleich und Offline-Betrieb selbst zu bauen kostet Wochen und bleibt fehleranfällig, Firestore bringt beides fertig mit. Ein kleines Team bekommt damit eine App auf ein Niveau, das früher eine eigene Serverlandschaft verlangt hätte. Google entwickelt Firebase sichtbar weiter, und die Plattform trägt einen erheblichen Teil der Apps in beiden App-Stores mit.

Als Universaldatenbank taugt Firestore dagegen nicht, und es will auch keine sein. Wer vor allem auswerten, verknüpfen und berichten will, ist mit PostgreSQL oder MySQL besser bedient, und wer volle Kontrolle über den Speicherort braucht, kommt an einer eigenen Datenbank nicht vorbei. Die ehrliche Zusammenfassung: Firestore lohnt sich genau dann, wenn seine beiden Stärken, Echtzeit und Betrieb ohne Server, im Zentrum eures Vorhabens stehen. Dann aber richtig.