Chapter 01 · Firestore Foundations, Firebase/Google Cloud, Editions, Modes, Locations, and Lab Setup
Standard vs Enterprise Editions and Native Core / Pipeline vs MongoDB Compatibility Modes
Compare Firestore Standard and Enterprise editions and separate Native Core, Native Pipeline, and MongoDB compatibility modes by query, indexing, realtime/offline, billing, and portability behavior.
Learning outcomes
AtlasMart can provision a database in seconds, but the first provisioning choice determines the query engine, index workflow, billing model, client capabilities, and migration surface. This lesson turns edition and mode labels into engineering decisions.
Compare Standard and Enterprise editions by query engine, indexing, billing and observability assumptions.
Separate Enterprise Native Core operations from Pipeline operations and explain why client capabilities differ.
Explain MongoDB compatibility as a distinct Enterprise mode rather than a transparent alias for Native Firestore or MongoDB.
Recognize which edition/mode properties can be demonstrated locally and which require production-only evidence.
Build an explicit decision record for AtlasMart instead of selecting an edition by feature count alone.
The reproducible lab pins Firebase CLI 15.30.0, Firebase JavaScript SDK 12.19.0, Firebase Admin Node.js SDK 14.4.0, and Node.js 22 or newer for the Admin SDK. These are a dated lab baseline, not permanent course guarantees. Firestore service capabilities, editions, pricing, locations, emulator fidelity and SDK support continue to evolve; re-check the official documentation before using the commands later.
The generation environment used to build this chapter does not run Firebase Emulator Suite or a billed Google Cloud project. Commands and API shapes were checked against current official documentation, but expected output is described by invariant and evidence shape rather than fabricated as captured output. The mandatory lab uses a Firebase demo project ID and local emulators. Optional production verification must use an isolated test project with explicit billing awareness.
1. Edition is a database-level architectural choice
Standard and Enterprise share the Firestore document model and managed-service identity, but their query engines and economics differ. In Standard Native mode, index-backed query execution is fundamental: single-field indexes are created automatically and composite indexes are added for query shapes that need them. In Enterprise Native mode, indexes are optional and are not automatically created for each field. An unindexed Enterprise query can execute by scanning data, which changes both diagnosis and cost reasoning.
This means “missing index” has edition-specific meaning. In Standard, a query that needs a missing composite index is normally rejected with guidance to create it. In Enterprise, a query may be valid but expensive because it scans. The same application query can therefore fail early in one edition and succeed slowly or expensively in another.
| Dimension | Standard Native | Enterprise Native |
|---|---|---|
| Query interface | Core operations | Core + Pipeline operations |
| Single-field indexes | Created automatically | Not created automatically |
| Index requirement | Queries require indexes | Indexes optional |
| Realtime/offline | Core supports both | Core path supports them; do not assume Pipeline parity |
| Billing model | Document/index-entry oriented Standard pricing | Unit-based Enterprise pricing |
| Advanced query surface | Core constraints | Pipeline adds broader operations |
2. Core operations are the shared document API surface
Core operations are the Firestore document CRUD/query operations familiar to web, mobile and server SDK users. They expose document gets, collection queries, writes, transactions and realtime listeners. Enterprise Native keeps Core operations so an application can use the familiar document API while benefiting from Enterprise infrastructure and optional indexing.
Do not infer identical cost or performance semantics merely because a Core SDK call has the same name. The edition's indexing rules and pricing model still matter. A migration test should compare query results, indexes/query plans, latency and billed work rather than only compile-time compatibility.
3. Pipeline operations are a distinct Enterprise query interface
Pipeline operations use a pipeline query model designed for a broader set of transforms, filters, aggregations and relational-style joins through sub-pipelines. The important architectural distinction is not syntax; it is that Pipeline is a separate operation family on the Enterprise query engine. A feature supported in Core is not automatically supported in Pipeline and vice versa.
Offline persistence and realtime listening are Core client capabilities. Do not design an offline mobile application around a Pipeline query until the exact SDK, operation and launch stage have been verified. Similarly, advanced Pipeline features can have their own release status. The course therefore records operation family and launch stage next to every advanced example.
4. MongoDB compatibility is a separate Enterprise mode
Firestore with MongoDB compatibility lets applications use supported MongoDB drivers, tools, BSON types and MQL against a Firestore-managed backend. This is valuable for migration and ecosystem reuse, but it is a compatibility contract, not proof of semantic identity with every MongoDB deployment and feature.
AtlasMart must inventory supported commands, transactions, indexes, data types, authentication, tools and operational assumptions before a port. A test suite—not a marketing label—establishes compatibility for the actual workload. Chapter 19 will perform that analysis in depth; Chapter 01 only establishes the boundary.
Never assume that Native Core, Pipeline and MongoDB-compatible operations are interchangeable surfaces. Name the mode and client protocol in every lab and architecture diagram.
5. Billing is part of correctness for a serverless design
A query that returns the correct documents but scans far more data than expected can still be operationally wrong. Standard pricing charges by document operations and relevant index-entry reads plus storage/network. Enterprise uses read/write units, with distinct treatment for realtime updates and data processed. The exact SKU numbers and prices are region- and time-sensitive, so this course treats pricing pages as live contracts rather than copying numbers into architecture folklore.
For a new feature, estimate the number and size of documents, query frequency, listener update rate, write fan-out, index footprint and retention. Then validate the estimate with production observability or Query Explain/Insights where applicable. “Serverless” shifts capacity planning toward usage and cost planning; it does not remove it.
6. Capability matrix: choose from requirements, not prestige
AtlasMart's mobile catalog requires offline-friendly product reads, realtime inventory badges and straightforward client Rules. Standard Native Core is a natural baseline. If a future admin analytics feature needs expressive server-side pipeline queries, Enterprise Native might justify the different billing and indexing model. If AtlasMart must port a MongoDB application with minimum protocol churn, MongoDB compatibility may be a candidate—but only after a workload compatibility test.
| Requirement | Likely starting point | Why |
|---|---|---|
| Mobile/web realtime + offline with simple document queries | Standard Native Core | Mature Core client path and index-backed query model |
| Same client model plus Enterprise governance/query-engine needs | Enterprise Native Core | Core API with Enterprise execution/billing |
| Complex server-side query pipelines / joins | Enterprise Native Pipeline | Broader query operations; verify feature stage/client support |
| Port supported MongoDB driver/tool workload | Enterprise MongoDB compatibility | Protocol/MQL compatibility; validate semantic gaps |
| Warehouse-scale ad-hoc analytics | External analytical system | Do not force operational document DB into warehouse role |
7. Deterministic local exercise: record the mode assumptions explicitly
The Emulator Suite can exercise Core document behavior and Security Rules, and current documentation states the Firestore emulator supports Enterprise edition configuration. It still does not reproduce every production query/index/concurrency behavior. For Chapter 01, keep the mandatory executable path to Core operations, then represent Enterprise/Pipeline/MongoDB choices as a decision record whose production claims must be verified separately.
# Lab assumptions (commit this beside the code)PROJECT_ID=demo-atlasmart-firestoreDATABASE_ID=(default)MANDATORY_PATH=Emulator SuiteCORE_CLIENT=Firebase Web SDK 12.19.0TRUSTED_SERVER=Firebase Admin Node.js 14.4.0FIREBASE_CLI=15.30.0NODE=22+PRODUCTION_EDITION=not-proven-by-emulatorPRODUCTION_MODE=not-proven-by-emulatorPRODUCTION_LOCATION=not-proven-by-emulatorPRODUCTION_BILLING=not-proven-by-emulatorIf a teammate writes “we tested Enterprise Pipeline locally” after running only this Core emulator fixture, the statement fails review. A good lab record says exactly which surface was exercised and which surface was only researched.
8. Wrong approach: choose Enterprise because it accepts unindexed queries
Optional indexing can look like freedom from schema/query design. In reality, an unindexed Enterprise query can scan a collection. A query that works on 200 test documents can become an expensive production scan at millions of documents. The repair is to use Query Explain/Insights and workload measurements, then add indexes where they reduce scanned work and improve latency/cost.
The mirror-image mistake in Standard is to create every possible composite index “just in case.” Extra indexes increase storage and write fan-out. In both editions, index design follows observed query contracts, not maximal feature coverage.
9. Production judgment and bridge
Write an architecture decision record that states edition, mode, operation family, required client capabilities, indexing strategy, billing model, regions, observability features, migration/exit path and assumptions that still need production proof. This small discipline prevents later chapters from silently mixing incompatible semantics.
The next lesson steps outward from the database engine to the Firebase project, Google Cloud project, database ID, location, billing account and shared responsibility boundary.
Knowledge check
Check your understanding
- What is the operational consequence of optional indexes in Enterprise?
- Which operation family provides Firestore realtime/offline client behavior?
- Why is MongoDB compatibility not evidence that every MongoDB workload is portable unchanged?
- Why can the same Core query require different performance reasoning in Standard and Enterprise?
- What must a local emulator exercise not be used to claim?
Review the answers
1. An Enterprise query can execute without an index and scan data; success no longer proves efficient execution. Query plans, scanned work, latency and cost must be measured.
2. Core operations provide the established realtime listener and offline persistence path. Pipeline operations are distinct and must be verified feature by feature.
3. Compatibility is bounded by supported protocol commands, data types, indexes, transactions, tools and service semantics. Only workload tests establish parity for the actual application.
4. Standard requires indexes and auto-creates single-field indexes; Enterprise makes indexes optional and uses a different billing/query engine. Identical API syntax does not imply identical scanned work or cost.
5. It must not be presented as proof of production region, billing, SLA, cloud IAM, exact index enforcement, production contention, or every Enterprise/Pipeline/MongoDB-compatible feature.
Summary and next step
Chapter 01 keeps Firestore claims tied to an observable state surface: client versus server, emulator versus production, project versus database, and Standard versus Enterprise/mode. Preserve the lab evidence and do not convert unknown production facts into assumptions.
Next, continue to Firebase Projects, Google Cloud Projects, Databases, Regions/Multi-Regions, Billing, and Responsibility Boundaries.
Authoritative references
- Cloud Firestore documentation — Official product documentation entry point.
- Firestore editions overview — Current Standard/Enterprise feature and indexing distinctions.
- Firestore Enterprise edition modes — Native Core/Pipeline and MongoDB compatibility mode boundaries.
- Firestore in Native mode / Pipeline operations — Current Enterprise Native operation model.
- Firestore security overview — Client Security Rules/App Check versus server IAM trust paths.
- Connect to the Firestore Emulator — Emulator connection guidance and documented differences from production.
- Firebase release notes — Current Firebase CLI and SDK versions.
- Compare Standard and Enterprise Native mode — Current indexing and query-engine differences.
- Firestore Enterprise pricing — Current unit-based Enterprise pricing model.
- MongoDB compatibility overview — Official compatibility scope.