Translate an Access Pattern Between Standard Core Queries and Enterprise Pipeline Operations and Compare Tradeoffs

1. AtlasMart capstone: choose an interface for the seller low-stock dashboard

The same business question can be implemented three ways: Standard Core, Enterprise Core, or Enterprise Pipeline. The final exercise deliberately avoids declaring a universal winner. Instead it builds a decision record from query expressiveness, realtime/offline needs, index semantics, Security Rules/IAM, billing, migration complexity and operational evidence.

Learning outcomes

2. Access-pattern contract

{  "caller": "seller-a operator",  "authorizedSellerId": "seller-a",  "filters": { "published": true, "stockLt": 10 },  "sort": ["stock asc", "name asc"],  "projection": ["name", "category", "stock", "price"],  "derived": ["inventoryValue = stock * price"],  "realtimeRequired": false,  "offlineRequired": false,  "maxInteractiveP95Ms": "team-defined; measure, do not invent",  "tenantBoundary": "backend must derive sellerId from verified identity"}

3. Standard Core implementation

const snap = await db.collection("catalogItems")  .where("sellerId", "==", "seller-a")  .where("published", "==", true)  .where("stock", "<", 10)  .orderBy("stock", "asc")  .get();const rows = snap.docs.map(d => ({...d.data(), inventoryValue:d.get("stock")*d.get("price")}));// Composite index may be required; Standard query must be index-backed.

Standard keeps a familiar and highly constrained execution model. The derived value is computed in application code unless materialized. Billing follows Standard document/index-entry pricing. For teams that already have working indexes and do not need Pipeline expressiveness, this may remain the lowest-complexity choice.

4. Enterprise Core implementation

const snap = await enterpriseDb.collection("catalogItems")  .where("sellerId", "==", "seller-a")  .where("published", "==", true)  .where("stock", "<", 10)  .orderBy("stock", "asc")  .get();// Same Core-shaped query. Indexes are optional in Enterprise; no index can mean a scan.

Enterprise Core preserves the familiar query path, including realtime/offline support when needed, but changes indexing and byte-based billing. Migration can therefore appear source-compatible while still changing performance/cost characteristics. Query Explain/Insights must enter the rollout checklist.

5. Enterprise Pipeline implementation

import { field } from "@google-cloud/firestore/pipelines";const p = enterpriseDb.pipeline()  .collection("catalogItems")  .where(field("sellerId").equal("seller-a"))  .where(field("published").equal(true))  .where(field("stock").lessThan(10))  .define(field("stock").multiply(field("price")).as("inventoryValue"))  .sort(field("stock").ascending())  .select("name", "category", "stock", "price", "inventoryValue");const result = await p.execute();

Pipeline moves projection/derived-field shaping into the query. That can simplify backend code and enables much richer composition, including subqueries and aggregations. It also introduces a second query interface, different Rules constraints, optional-index scan risk and feature-stage tracking.

6. Tradeoff matrix

7. Migration without a cold full-traffic cutover

1. Create an isolated Enterprise Native database in a supported location; database location cannot later be changed.
2. Replicate a bounded, non-sensitive AtlasMart fixture and build expected-result contracts.
3. Run Standard Core and Enterprise Core shadow comparisons first.
4. Add candidate Enterprise indexes based on observed scans.
5. Introduce Pipeline only for access patterns that need it; keep Core for realtime/offline paths.
6. Capture managed Query Explain, p50/p95/p99, Read/Write Units and Security Rules/IAM tests.
7. Ramp traffic gradually with rollback to Standard until correctness/cost/SLO gates hold.

8. Failure injection: remove the Enterprise index during shadow traffic

The expected rows should stay correct while query-plan and latency/cost evidence degrades. The test validates observability and rollback. Do not perform destructive index experiments on a production database serving uncontrolled traffic.

assert.deepEqual(normalize(standardRows), normalize(enterpriseCoreRows));assert.deepEqual(normalize(standardRows), normalize(enterprisePipelineRows));console.log({  correctness:"match",  standardPlan:"capture separately",  enterpriseCoreExplain:"capture managed",  enterprisePipelineExplain:"capture managed"});

9. When Standard remains simpler

If AtlasMart primarily needs direct document reads, predictable indexed Core queries, realtime listeners and offline mobile/web behavior, and does not benefit materially from Pipeline's query expressiveness or Enterprise-specific capabilities, Standard can remain the simpler operational choice. Enterprise should solve a measured problem—not serve as an automatic “higher tier” upgrade.

10. Chapter 18 acceptance record

• Same six-product AtlasMart fixture is used across Core/Pipeline examples.
• Standard and Enterprise billing/indexing differences are explicit.
• Enterprise unindexed success is never treated as efficiency evidence.
• Pipeline DML and search are labeled Preview.
• Server/Admin IAM bypass of Rules is not confused with end-user authorization.
• Realtime/offline requirements route to Core.
• Query Explain metrics are captured only from a real supported Enterprise database; local values remain simulations.

Production judgment and bridge to Chapter 19

AtlasMart can now reason about Enterprise Native as an execution model rather than a feature list: Core preserves application continuity while changing index/billing behavior; Pipeline adds a composable query engine with new power and new operational obligations. Chapter 19 changes mode entirely and studies Firestore with MongoDB compatibility—drivers, BSON/MQL, tooling and the boundaries of “compatibility.”

Knowledge check

1. Which option should AtlasMart use for realtime/offline behavior inside Enterprise Native?
2. Why can Enterprise Core migration look deceptively easy?
3. When is Pipeline justified?
4. What should a Standard→Enterprise shadow test compare first?
5. Is Enterprise automatically preferable to Standard?

Authoritative references

• Firebase · Overview of Firestore in Native mode (Core and Pipeline operations)
• Firebase · Standard vs Enterprise Native mode support
• Firebase · Get data with Pipeline operations
• Firebase · Perform joins with sub-pipelines
• Firebase · Query Explain for Enterprise
• Firebase · Enterprise Native index overview
• Firebase · Pipeline DML stages (Preview)
• Firebase · Pipeline search stage (Preview)
• Google Cloud · Firestore Enterprise pricing
• Firebase · Connect to the Firestore emulator / Enterprise edition configuration