Firexport / Blog

Die Edition, die Sie beim Anlegen einer Firestore-Datenbank wählen, Standard oder Enterprise, lässt sich später nicht ändern. Seit der native Modus der Enterprise-Edition im April 2026 allgemein verfügbar (GA) wurde, starten neue Apps besser mit Enterprise. Unter einer Bedingung: Um Indexe und den Zugriff von Clients kümmern Sie sich selbst.

Warum Enterprise die bessere Voreinstellung ist

1. Kein Wechsel möglich, also dort anfangen, wo Sie seltener festsitzen

Die Edition wird beim Anlegen der Datenbank festgelegt und ändert sich danach nicht. Ein Wechsel bedeutet: Daten in eine neue Datenbank verschieben, Indexe sowie TTL- und Backup-Einstellungen neu anlegen und eine neue App-Version veröffentlichen, die auf die neue Datenbank zeigt (Migrationsanleitung).

Starten Sie deshalb auf der Seite, auf der Sie seltener festsitzen. Bei Standard stoßen Sie an fehlende Funktionen wie Suche, Aggregation oder Joins, die Sie nur per Migration oder Umbau umgehen. Bei Enterprise ist es meist ein fehlender Index, und den stellen Sie bereit, ohne Code oder Daten anzufassen.

2. Gleicher Code, mehr Abfragen

Der native Modus von Enterprise nutzt dieselben Firebase SDKs und dieselben Abfragen (Core-Operationen) wie Standard. where(), orderBy(), onSnapshot()-Listener, der Offline-Cache und Sicherheitsregeln funktionieren unverändert, und er unterstützt den lokalen Emulator, Trigger für Cloud Functions (2. Generation), dieselben Regionen wie Standard und das kostenlose Kontingent des Spark-Tarifs. Anders ist die Sortierung: Dokumente mit gleichem Sortierwert werden nicht nach Dokument-ID geordnet. Wenn Sie mit Cursorn paginieren, ergänzen Sie orderBy deshalb um die Dokument-ID.

Dazu kommen Pipeline-Abfragen. Was Sie bei Standard umgehen mussten, wird zu einer einzigen Abfrage.

Text- und Geosuche sowie Massenänderungen und -löschungen (DML) sind seit Oktober 2026 allgemein verfügbar. Pipelines sind allerdings einmalige Lesevorgänge: Sie haben keine Echtzeit-Listener und keinen Offline-Betrieb, und Sicherheitsregeln verstehen bei Pipelines nur einfache Filter, die ein Feld mit einer Konstanten vergleichen. Lassen Sie Listen auf dem Bildschirm und Live-Updates bei Core-Abfragen, nutzen Sie Pipelines für Suche, Aggregation und Berichte, und führen Sie komplexe Pipelines auf dem Server aus (Admin SDK, Cloud Functions).

3. Lesevorgänge mit Index kosten weniger

Standard rechnet nach Anzahl der Dokumente ab, Enterprise nach gelesenen und geschriebenen Bytes. Das sind die Preise für us-central1 im November 2026.

• Lesen: Ein Dokument bis 4 KiB per ID zu lesen kostet bei Enterprise ein Sechstel, bis 24 KiB gleich viel oder weniger. Abfragen zahlen zusätzlich das Lesen des Index: Mit einem Ergebnis kosten sie ein Drittel, mit mehr Ergebnissen nähern sie sich einem Sechstel.
• Schreiben: Ein neues 1-KiB-Dokument ist bei Enterprise mit bis zu 2 Indexeinträgen günstiger (0,78 $ pro Million) und ab 3 teurer (1,04 $). Updates, die ein indexiertes Feld ändern, kosten 2 Einheiten pro geändertem Eintrag und werden daher früher teurer.
• Löschen: Schon das kleinste Dokument kostet 1 Einheit (0,26 $), also immer mehr als bei Standard (0,10 $).

Liest Ihre App viel mehr, als sie schreibt, ist Enterprise günstiger. Schreibt und löscht sie viel, rechnen Sie das vorher mit Ihren Dokumentgrößen und Ihrer Zahl an Indexen nach.

Der Preis: Indexe und Zugriff liegen bei Ihnen

Standard führt nur Abfragen aus, die ein Index bedienen kann. Jedes Feld bekommt automatisch einen Index, und eine Abfrage, die einen zusammengesetzten Index braucht, scheitert mit einer Fehlermeldung samt Link zum Anlegen. Die Kosten einer Abfrage hängen deshalb nur von der Zahl der Ergebnisse ab.

Enterprise legt keine Indexe an und führt Abfragen auch ohne aus. Dafür liest es die ganze Sammlung und berechnet die gelesenen Bytes, und es sortiert im Speicher, was an das Speicherlimit pro Abfrage (128 MiB) stoßen kann. Weil keine Fehlermeldung kommt, fällt das in der Entwicklung mit ein paar Dutzend Dokumenten nicht auf; es zeigt sich erst, wenn die Daten wachsen.

So viel kostet es, eine Abfrage, die einen Nutzer anhand seines Nutzernamens findet, eine Million Mal auszuführen. Die Dokumente sind 2 KiB groß; die erste Zeile ist Googles Preisbeispiel, die zweite dieselbe Rechnung mit 100.000 Dokumenten.

Ein einziger Index macht bei derselben Abfrage einen Unterschied um das 25.000-Fache (100.000 × 2 KiB ÷ 4 KiB = 50.000 Einheiten pro Abfrage).

Diesen Unterschied können auch andere nutzen. Dürfen Clients eine Sammlung auflisten, kann jeder einen Filter auf ein nicht indexiertes Feld setzen und Firestore alles durchsuchen lassen, was er lesen darf. Weil nichts passt, hilft limit nicht, und Sicherheitsregeln können einen zusätzlichen Filter in einer Abfrage nicht verhindern. Bei Standard scheitert eine solche Abfrage einfach.

Vier Gewohnheiten

1. Schreiben Sie den Index zusammen mit der Abfrage. Legen Sie für jede Kombination aus where und orderBy auf einer weiter wachsenden Sammlung einen Index in firestore.indexes.json an und stellen Sie ihn mit firebase deploy --only firestore:indexes bereit. Das gilt auch für die Einzelfeldindexe, die Standard automatisch angelegt hat. Lesevorgänge per Dokument-ID brauchen keinen Index. Das ist der Index für where('authorId', '==', uid).orderBy('createdAt', 'desc'):

   {
     "indexes": [
       {
         "collectionGroup": "posts",
         "queryScope": "COLLECTION",
         "fields": [
           { "fieldPath": "authorId", "order": "ASCENDING" },
           { "fieldPath": "createdAt", "order": "DESCENDING" }
         ]
       }
     ]
   }

2. Prüfen Sie vor dem Release mit Query Explain. Führen Sie in der Firebase Console dieselbe Abfrage im Abfrageeditor (Query Editor) auf dem Tab „Daten“ (Data) von Firestore aus und öffnen Sie den Tab Query Explain. Steht ganz unten im Ausführungsbaum TableScan, wurde die ganze Sammlung ohne Index gelesen.
3. Begrenzen Sie den Client-Zugriff. Erzwingen Sie App Check, um Anfragen abzuweisen, die nicht aus Ihrer App kommen, und binden Sie Listen-Lesevorgänge per Sicherheitsregel an eine Gleichheit auf einem indexierten Feld, etwa resource.data.ownerId == request.auth.uid. Dann bleibt ein Scan, falls ihn jemand auslöst, auf die Dokumente dieses Nutzers beschränkt.
4. Aktivieren Sie Query Insights und Budgetbenachrichtigungen. Query Insights zeigt Ihre häufigen Abfragen und ihre Leistung und damit, wo ein Index fehlt. Im Blaze-Tarif richten Sie außerdem eine Budgetbenachrichtigung in Cloud Billing ein.

Mit Enterprise starten

Öffnen Sie in der Firebase Console Firestore, klicken Sie auf „Datenbank erstellen“ (Create database), wählen Sie Enterprise und den nativen Modus (Native mode) und legen Sie ID und Standort fest. Lassen Sie Echtzeit-Updates (Realtime Updates) eingeschaltet, so ist es voreingestellt. Sie lassen sich später nicht ändern, und eine ohne sie angelegte Datenbank kann keine Listener bedienen. Danach unterscheiden sich drei Dinge von Standard.

1. Übergeben Sie die Datenbank-ID im Code. Eine Enterprise-Datenbank ist eine Datenbank, die Sie selbst benennen; (default) gibt es nur bei Standard. Die SDKs verbinden sich mit (default), solange Sie nichts anderes angeben.

   // Web
   const db = getFirestore(app, 'app-db');
   
   // Android (Kotlin)
   val db = FirebaseFirestore.getInstance("app-db")
   
   // iOS (Swift)
   let db = Firestore.firestore(database: "app-db")
   
   // Flutter
   final db = FirebaseFirestore.instanceFor(
       app: Firebase.app(), databaseId: 'app-db');

2. Tragen Sie Datenbank und Edition in firebase.json ein. Dann werden Regeln und Indexe in dieser Datenbank bereitgestellt, und der Emulator startet als Enterprise. Legen Sie die Datenbank zuerst in der Console an. Gibt es die eingetragene Datenbank nicht, legt firebase deploy sie an, und Firebase CLI 15.12 erstellt sie dann im MongoDB-kompatiblen Modus, den die Firebase SDKs nicht nutzen können.

   {
     "firestore": {
       "database": "app-db",
       "edition": "enterprise",
       "rules": "firestore.rules",
       "indexes": "firestore.indexes.json"
     }
   }

3. Das kostenlose Kontingent erhält nur die zuerst angelegte Datenbank. Hat das Projekt eine ungenutzte Standard-Datenbank, löschen Sie sie, bevor Sie die Enterprise-Datenbank anlegen, damit das Kontingent an Enterprise geht.

Wann Standard weiterhin besser ist

• Apps, die schon auf Standard laufen. Migrieren Sie erst, wenn Sie Pipelines wirklich brauchen.
• Projekte, in denen sich niemand um Abfragen und Indexe kümmert. Dass Standard Abfragen ohne Index gar nicht ausführt, ist Ihr Sicherheitsnetz.
• Apps, deren Clients große öffentliche Sammlungen direkt lesen. Bei öffentlichen Listen, die Regeln nicht eingrenzen können, kann jeder einen vollständigen Scan auslösen.
• Apps, die viel schreiben und löschen oder vor allem große Dokumente lesen. Jenseits der Schwellen oben ist Standard günstiger.
• Wenn Sie Tools brauchen, die die (default)-Datenbank oder Cloud Functions der 1. Generation voraussetzen. Enterprise-Datenbanken haben einen eigenen Namen, und Trigger der 1. Generation unterstützen sie nicht.

Quellen

• Firestore-Editionen, Editionen im nativen Modus im Vergleich, Überblick über den nativen Modus von Enterprise: Unterschiede bei Funktionen, Indexen, Sortierung und Scans
• Enterprise-Preise, Preisbeispiele für Abfragen, Preisbeispiele für Schreib- und Löschvorgänge, Firebase-Preise: Preise und kostenloses Kontingent
• Von Standard zu Enterprise migrieren, Firestore-Versionshinweise
• Erste Schritte mit Enterprise, Datenbanken verwalten, Datenbankeinstellungen (REST), Standorte, Kontingente und kostenlose Nutzung
• Enterprise-Indexe, JSON-Format für Indexe, Query Explain, Query Insights
• Sicherheitsregeln für Pipelines, App Check, Cloud Functions-Trigger, Emulator