Add Aggregation, Vector Retrieval, Enterprise Pipeline or MongoDB Compatibility Only Where Requirements Justify Them

1. Advanced capability review: earn complexity with evidence

AtlasMart stakeholders now ask for “live sales totals,” “semantic product search,” “joins,” and “MongoDB compatibility.” Those phrases map to very different mechanisms. The capstone does not enable them by default. It creates a decision gate for each one: requirement, supported interface, launch stage, client/server boundary, index/cost model, security path, measurable success criterion and fallback.

2. Capability gate matrix

3. Aggregation: operational answer, not analytics strategy

// Standard Native server-side operational aggregateconst q = db.collection("orders")  .where("ownerUid", "==", uid)  .where("status", "==", "completed");const countSnap = await q.count().get();console.log({ completedOrders: countSnap.data().count });

Read-time aggregation is useful when the indexed scan remains bounded by the operational access pattern. It is billed according to current aggregation/index-entry semantics, is not a realtime listener, and should not be repeated across huge historical datasets as a substitute for an analytical system. For a realtime dashboard with strict latency and high query frequency, a transactionally or event-maintained summary may be more appropriate—at the cost of write amplification and reconciliation logic.

4. Vector retrieval: search vectors, do not invent semantics

Firestore stores/searches vector values; it does not generate embeddings. Standard vector search currently supports a maximum embedding dimension of 2,048, a maximum 1,000 returned documents per nearest-neighbor query, no realtime snapshot listener, and server client support rather than the ordinary browser/mobile listener path. AtlasMart therefore treats semantic search as an optional backend capability.

// Learning fixture only: not a semantic model.const embeddings = {  "red ceramic mug": [0.91, 0.11, 0.02, 0.34],  "steel water bottle": [0.08, 0.88, 0.14, 0.22],  "insulated travel cup": [0.62, 0.41, 0.07, 0.51]};const embeddingMeta = {  provider: "deterministic-course-fixture",  model: "atlasmart-4d-v1",  dimensions: 4,  normalization: "unit-like fixture",  generatedAt: "2026-09-17"};

A production vector feature needs model/provider/version/dimensions/normalization metadata, backfill/update behavior, authorization-preserving metadata filters, recall/relevance evaluation, latency and cost. A small cosine score is not proof of business relevance.

5. Enterprise Native: Core and Pipeline are different interfaces

Current Firestore release notes mark Enterprise Native and Pipeline as GA. Enterprise indexing is optional rather than automatically created as in Standard, and the pricing model is byte/unit based. Pipeline can add richer composable server-side operations and subquery joins. But client offline/realtime behavior and launch stage are feature-specific: Pipeline text/geospatial search and Pipeline DML stages are currently Preview, so the capstone must not treat “Enterprise” as one uniformly GA surface.

6. MongoDB compatibility: compatibility surface, not database identity

Firestore with MongoDB compatibility is an Enterprise mode intended for applications that need MongoDB drivers/tools/API compatibility. It is not mongod running in Google Cloud and should not inherit MongoDB operational assumptions, supported-command assumptions, transaction/change-stream assumptions, index definitions or security roles without testing.

{  "capability": "mongodb-compatibility",  "launchDecision": "REJECT",  "reason": "AtlasMart has no MongoDB driver/tool/migration dependency",  "reconsiderIf": [    "legacy service must retain a supported MongoDB driver/ODM",    "migration program requires compatible endpoint",    "compatibility test matrix passes queries/types/indexes/transactions/tools"  ],  "neverAssume": "drop-in equivalence"}

7. Deliberately wrong approach: “advanced” means “better”

The repair is to keep capabilities mutually explicit. Standard Native Core remains the launch contract. Optional vector search is one server-side feature flag. Enterprise/Pipeline and MongoDB compatibility are alternative database/interface decisions, not transparent decorations on the same request path.

8. Mandatory local lab: capability evaluation harness

1. Run the core AtlasMart product search fixture by tags/category and record top results.
2. Run deterministic 4-D vector similarity over the same products and compute a small relevance fixture (precision@3 or judged top-3).
3. Run a local operational order count and a materialized summary; intentionally corrupt the summary and demonstrate reconciliation.
4. Create decision JSON files for aggregation, vector, Enterprise Pipeline and MongoDB compatibility with ACCEPT/REJECT, evidence and rollback.
5. Do not claim real vector index latency, Enterprise RU/WU economics, Pipeline query plans or MongoDB driver parity from the local simulation; mark those VERIFY_MANAGED.

const judgedRelevant = new Set(["p-mug-red", "p-travel-cup"]);const returned = ["p-mug-red", "p-bottle-steel", "p-travel-cup"];const hits = returned.filter(id => judgedRelevant.has(id)).length;const precisionAt3 = hits / returned.length;console.log({ precisionAt3 });if (precisionAt3 < 0.66) throw new Error("vector feature does not earn launch complexity");

Production judgment and bridge

Architecture maturity includes saying “not yet.” Lesson 4 stress-tests the chosen design: hotspots, offline conflicts, Rules, recovery, observability and rollback. The goal is to discover whether the apparently simple Standard/Core design survives adverse conditions.

Knowledge check

1. Why is a Firestore aggregation not automatically a warehouse workload?
2. What metadata must accompany stored embeddings?
3. What is the current launch status of Enterprise Native/Pipeline versus Pipeline text/geospatial/DML?
4. Why is MongoDB compatibility rejected for AtlasMart launch?
5. What kind of evidence can justify revisiting Standard?

Authoritative references

• Firebase: Cloud Firestore documentation — Standard Native/Core application semantics.
• Firebase: Security Rules conditions — Rules are not filters and server libraries bypass Rules in favor of IAM/ADC.
• Firebase: Connect to the Cloud Firestore emulator — demo projects and emulator/production differences.
• Firebase: Transactions and batched writes — retries, atomicity and offline constraints.
• Firebase: Firestore best practices — hotspot avoidance and gradual traffic ramping.
• Firebase: Firestore pricing — document/index-entry/listener/aggregation billing in Standard.
• Firebase: Vector search — vector indexes, dimensions, query limits and supported server SDKs.
• Google Cloud: Firestore release notes — current Enterprise/Pipeline launch status and product changes.
• Google Cloud: Core and Pipeline query interfaces — Standard/Enterprise indexing and query-interface differences.
• Google Cloud: Firestore with MongoDB compatibility overview — serverless compatibility surface, not MongoDB itself.
• Google Cloud: Firestore backups and restore — managed recovery mechanisms.
• Google Cloud: Point-in-time recovery — historical recovery window and managed semantics.