Firexport logo

FirexportBlog

Firestore Enterprise vs Standard: start new apps on Enterprise

The edition you pick when you create a Firestore database, Standard or Enterprise, can’t be changed later. Now that the Enterprise edition’s Native mode has been generally available (GA) since April 2026, new apps are better off starting on Enterprise. On one condition: you look after indexes and client access yourself.

In short

  • Pick the one you’re less likely to get stuck on. Standard’s limits only lift when you move your data; Enterprise’s problems are usually fixed by deploying an index. Why
  • Same code, more queries. Realtime listeners, offline support and security rules work as on Standard, and Pipeline queries add search, aggregation and joins. What you gain
  • Indexed reads cost less. Reading a document of 4 KiB or less by ID costs a sixth of what it does on Standard. Writes get pricier the more indexes you have, and deletes always cost more. Prices
  • Indexes and access are on you. A query without an index reads the whole collection without an error, and someone else can make that happen on purpose. What to do

Why Enterprise is the better default

1. You can’t switch, so start where you’re less likely to get stuck

The edition is set when the database is created and never changes. Switching means moving the data to a new database, recreating indexes and TTL and backup settings, and shipping a new version of your app that points at the new database (migration guide).

So start on the side you’re less likely to get stuck on. What stops you on Standard is missing features such as search, aggregation and joins, which you get around by migrating or restructuring. What stops you on Enterprise is usually a missing index, and you deploy one without touching your code or data.

2. The same code, plus more queries

Enterprise’s Native mode uses the same Firebase SDKs and the same queries (Core operations) as Standard. where(), orderBy(), onSnapshot() listeners, the offline cache and security rules work unchanged, and it supports the local emulator, Cloud Functions (2nd gen) triggers, the same regions as Standard, and the Spark plan’s free usage. Sorting is the one difference: documents with the same sort value aren’t ordered by document ID for you, so if you paginate with cursors, add the document ID to your orderBy.

On top of that come Pipeline queries. What you had to work around on Standard becomes a single query.

What you wantStandardEnterprise
Full-text searchSync to an external search service (Algolia etc.)Text search
Places within a radiusAdd a geohash field and run range queriesGeospatial search
Match part of a string or a regexPrefix matches onlystr_contains, regex_match
Totals per group, distinct countsAggregate each group separately or keep counter documentsOne aggregate stage
Read across collectionsDenormalize or read several timesSubquery joins
Update or delete everything that matchesA script that reads, then writes in batchesupdate and delete stages
Prevent duplicate valuesA document keyed by the value, plus a transactionUnique index

Text and geospatial search and bulk updates and deletes (DML) became generally available in October 2026. Pipelines are one-off reads, though: they have no realtime listeners or offline support, and security rules only understand simple Pipeline filters that compare a field with a constant. Keep on-screen lists and live updates on Core queries, use Pipelines for search, aggregation and reports, and run complex Pipelines on the server (Admin SDK, Cloud Functions).

3. Indexed reads cost less

Standard charges by the number of documents, Enterprise by the bytes read and written. These are us-central1’s prices as of November 2026.

StandardEnterprise
Reads$0.30 per million documents1 unit per 4 KiB, $0.05 per million units
Writes$0.90 per million documents, index updates free1 unit per 1 KiB, $0.26 per million units, plus 1 unit per index entry
Deletes$0.10 per million documentsWrite units (document + index entries)
Realtime updatesCounted as reads, $0.30 per million1 unit per 4 KiB, $0.30 per million units. Same price for documents up to 4 KiB
StorageAbout $0.15 per GiB per month, including the automatic indexes on every fieldAbout $0.23 per GiB per month, only the indexes you create
Free per day50,000 reads, 20,000 writes, 20,000 deletes50,000 read, 40,000 write and 50,000 realtime update units
  • Reads: reading a document of 4 KiB or less by ID costs a sixth on Enterprise, and the same or less up to 24 KiB. Queries also pay to read the index, so a query with one result costs a third, and the more results, the closer it gets to a sixth.
  • Writes: creating a 1 KiB document is cheaper on Enterprise with up to 2 index entries ($0.78 per million) and dearer from 3 ($1.04). Updates that change an indexed field cost 2 units per changed entry, so they get pricier sooner.
  • Deletes: even the smallest document costs 1 unit ($0.26), so deletes always cost more than on Standard ($0.10).

If your app reads far more than it writes, Enterprise is cheaper. If it writes and deletes a lot, run these numbers with your document sizes and index counts first.

The catch: indexes and access are on you

Standard only runs queries an index can serve. Every field gets an index automatically, and a query that needs a composite index fails with an error that links to creating it. So a query’s cost follows only the number of results.

Enterprise creates no indexes and runs queries without them. Instead it reads the whole collection and bills for the bytes read, and it sorts in memory, which can hit the per-query memory limit (128 MiB). With no error, nothing shows while you develop against a few dozen documents; it surfaces as the data grows.

Here is what a query that finds one user by username costs when it runs a million times. Documents are 2 KiB; the first row is Google’s pricing example, the second the same calculation with 100,000 documents.

CollectionStandard (automatic index)Enterprise (with index)Enterprise (no index)
100 documents$0.30$0.10$2.50
100,000 documents$0.30$0.10$2,500

One index makes a 25,000-fold difference to what the same query costs (100,000 × 2 KiB ÷ 4 KiB = 50,000 units per query).

Others can use that gap too. If clients can list a collection, anyone can add a filter on an unindexed field and make Firestore scan everything they’re allowed to read. Nothing matches, so limit doesn’t help, and security rules can’t block a filter added to a query. On Standard, such a query just fails.

Four habits

  1. Write the index when you write the query. For every where and orderBy combination on a collection that keeps growing, add an index to firestore.indexes.json and deploy it with firebase deploy --only firestore:indexes. That includes the single-field indexes Standard used to create for you. Reads by document ID need no index. This is the index for where('authorId', '==', uid).orderBy('createdAt', 'desc'):
    {
  "indexes": [
    {
      "collectionGroup": "posts",
      "queryScope": "COLLECTION",
      "fields": [
        { "fieldPath": "authorId", "order": "ASCENDING" },
        { "fieldPath": "createdAt", "order": "DESCENDING" }
      ]
    }
  ]
}
  2. Check with Query Explain before you ship. In the Firebase console, run the same query in the Query Editor on Firestore’s Data tab and open the Query Explain tab. If the bottom of the execution tree is TableScan, the query read the whole collection without an index.
  3. Lock down client access. Enforce App Check to reject requests that don’t come from your app, and use security rules to tie list reads to an equality on an indexed field, such as resource.data.ownerId == request.auth.uid. Then a scan, if someone triggers one, stays within that user’s documents.
  4. Turn on Query Insights and budget alerts. Query Insights shows your frequent queries and how they perform, which tells you where an index is missing. On the Blaze plan, also set a Cloud Billing budget alert.

Starting on Enterprise

In the Firebase console, open Firestore, click Create database, choose Enterprise and Native mode, then set an ID and a location. Leave Realtime Updates on, which is the default. It can’t be changed later, and a database created without it can’t serve listeners. After that, three things differ from Standard.

  1. Pass the database ID in your code. An Enterprise database is one you name yourself; (default) exists only on Standard. The SDKs connect to (default) unless told otherwise.
    // 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. Name the database and edition in firebase.json. Rules and indexes then deploy to that database, and the emulator starts as Enterprise. Create the database in the console first. If the database named there doesn’t exist, firebase deploy creates it, and Firebase CLI 15.12 creates it in MongoDB compatibility mode, which the Firebase SDKs can’t use.
    {
  "firestore": {
    "database": "app-db",
    "edition": "enterprise",
    "rules": "firestore.rules",
    "indexes": "firestore.indexes.json"
  }
}
  3. The free tier goes to the first database you create, and only that one. If the project has a Standard database you don’t use, delete it before you create the Enterprise one, so the free tier goes to Enterprise.

When Standard is still the better choice

  • Apps already running on Standard. Don’t move until you actually need Pipelines.
  • Projects with nobody to look after queries and indexes. Standard’s refusal to run unindexed queries is your safety net.
  • Apps whose clients read large public collections directly. Public lists that rules can’t narrow let anyone trigger a full scan.
  • Apps that write and delete a lot, or mostly read large documents. Past the break-even points above, Standard is cheaper.
  • When you need tools that assume the (default) database or Cloud Functions 1st gen. Enterprise databases are named, and 1st gen triggers don’t support them.

Sources

All posts →