Aggregations with Filters / Collection Groups and Consistency Expectations

1. AtlasMart problem: a correct aggregate can still be an invalid or insecure query

Operations wants “total order value for seller-a” across every user’s nested orders subcollection. That is not a single collection read; it is a collection-group query. The aggregation inherits that query’s scope, filters, index requirements and authorization constraints. Firestore Security Rules do not post-filter the aggregate. If the query could return a document the caller is not allowed to read, the request is denied rather than silently subtracting that document from the total.

Learning outcomes

2. Fixture truth across nested parents

process.env.FIRESTORE_EMULATOR_HOST = "127.0.0.1:8080";process.env.GCLOUD_PROJECT = "demo-atlasmart-firestore";import { initializeApp } from "firebase-admin/app";import { getFirestore, Timestamp } from "firebase-admin/firestore";initializeApp({ projectId: "demo-atlasmart-firestore" });const db = getFirestore();const t = (s) => Timestamp.fromDate(new Date(s));await db.doc("products/p-1001").set({  name: "Trail Camera", public: true, sellerId: "seller-a", schemaVersion: 4});const reviews = {  "r-001": { userId: "u-alice", published: true,  rating: 5,   body: "Excellent", createdAt: t("2026-09-01T10:00:00Z") },  "r-002": { userId: "u-bob",   published: true,  rating: 4,   body: "Good",      createdAt: t("2026-09-02T10:00:00Z") },  "r-003": { userId: "u-cara",  published: false, rating: 2,   body: "Draft",     createdAt: t("2026-09-03T10:00:00Z") },  "r-004": { userId: "u-dan",   published: true,  rating: 3,   body: "Okay",      createdAt: t("2026-09-04T10:00:00Z") },  "r-005": { userId: "u-erin",  published: true,  rating: "5", body: "Legacy",    createdAt: t("2026-09-05T10:00:00Z") },  "r-006": { userId: "u-faye",  published: true,               body: "No score",  createdAt: t("2026-09-06T10:00:00Z") }};for (const [id, data] of Object.entries(reviews)) {  await db.doc(`products/p-1001/reviews/${id}`).set(data);}await db.doc("users/u-alice/orders/o-1001").set({  ownerUid: "u-alice", tenantId: "seller-a", status: "paid",  totalCents: 19800, createdAt: t("2026-09-10T10:00:00Z")});await db.doc("users/u-alice/orders/o-1002").set({  ownerUid: "u-alice", tenantId: "seller-b", status: "shipped",  totalCents: 4900, createdAt: t("2026-09-11T10:00:00Z")});await db.doc("users/u-bob/orders/o-1003").set({  ownerUid: "u-bob", tenantId: "seller-a", status: "paid",  totalCents: 9900, createdAt: t("2026-09-12T10:00:00Z")});console.log(JSON.stringify({  expected: {    publishedReviewDocuments: 5,    publishedNumericRatings: 3,    publishedRatingSum: 12,    publishedRatingAverage: 4,    sellerAOrders: 2,    sellerAOrderTotalCents: 29700,    sellerAOrderAverageCents: 14850  }}, null, 2));

The seller-a collection-group query spans users/u-alice/orders/o-1001 and users/u-bob/orders/o-1003. Its truth is 2 orders, 29,700 cents total and 14,850 cents average. The seller-b order is not part of that filter.

{  "indexes": [    {      "collectionGroup": "orders",      "queryScope": "COLLECTION_GROUP",      "fields": [        { "fieldPath": "tenantId", "order": "ASCENDING" },        { "fieldPath": "createdAt", "order": "DESCENDING" }      ]    }  ],  "fieldOverrides": [    {      "collectionGroup": "reviews",      "fieldPath": "body",      "indexes": []    }  ]}

3. Filtered and collection-group aggregations reuse query semantics

import {  collection, collectionGroup, query, where,  getAggregateFromServer, count, sum, average} from "firebase/firestore";export async function publishedRatingTruth(db) {  const q = query(    collection(db, "products", "p-1001", "reviews"),    where("published", "==", true)  );  const snap = await getAggregateFromServer(q, {    documents: count(),    ratingSum: sum("rating"),    ratingAverage: average("rating")  });  return snap.data();}export async function sellerAOrderTruth(db) {  const q = query(collectionGroup(db, "orders"), where("tenantId", "==", "seller-a"));  const snap = await getAggregateFromServer(q, {    orders: count(),    totalCents: sum("totalCents"),    averageCents: average("totalCents")  });  return snap.data();}

Nothing about count() or sum() weakens the query contract. A filter that needs a composite/collection-group index in Standard still needs that index in production. The emulator does not enforce compound indexes, so a locally successful aggregation does not prove the managed index exists or is READY.

4. Rules are not aggregate filters

Suppose Alice is allowed to read only documents whose ownerUid == request.auth.uid. A client collection-group query constrained only by tenantId == "seller-a" could match Bob’s order as well as Alice’s. Firestore cannot “sum Alice’s permitted row and hide Bob’s.” The query must be provably compatible with the rules, for example by including an ownership filter whose semantics line up with the rule, or the aggregation must run through a trusted backend that performs its own application authorization under IAM.

5. Allowed/denied query matrix

6. Consistency expectation: fresh server answer, not a subscription

A direct aggregation returns a backend result for that request. It does not create a listener and does not update automatically when a new order arrives one second later. If the UI refreshes every 30 seconds, the product requirement is “server aggregate refreshed at most every 30 seconds,” not “realtime.” If users need immediate local feedback after placing an order, show pending local workflow state separately until the authoritative aggregate refreshes.

7. Boundary cases that change the population

8. Deliberately wrong approach: aggregate broadly, then hide the result in UI

UI hiding is not authorization. An attacker can call the SDK directly. A broad aggregate can expose counts, averages or revenue even if the individual documents never render. Repair the design by making query scope/rules provably compatible or routing privileged aggregate work through a backend that verifies the caller and seller/tenant relationship before executing with its workload identity.

9. Emulator vs production evidence

The local emulator is ideal for deterministic fixtures and Security Rules assertions. It is not authoritative for compound-index enforcement, managed query planning, production billing, regional latency or Enterprise scan cost. A bounded optional managed verification should record the exact project, database, edition, location, index state, query shape and Query Explain evidence; do not paste production credentials into course code.

Production judgment and bridge to Lesson 3

Filtered aggregation is attractive when the query is bounded and the application can tolerate request/refresh semantics. Repeatedly computing the same product rating or dashboard total on every view eventually trades write simplicity for read cost and latency. Lesson 3 asks when to materialize the answer and accept write amplification, consistency/repair responsibility and potential hotspot risk.

Knowledge check

1. Do Security Rules filter an aggregation result?
2. Why is collectionGroup scope security-sensitive?
3. Does a locally successful composite aggregation prove the production index exists?
4. Is a server aggregation a realtime subscription?
5. What changes in Enterprise if an index is missing?

Summary

Aggregation inherits query scope. AtlasMart now treats filters, collection groups, rules, indexes and refresh semantics as part of the aggregate contract rather than as implementation details.

Authoritative references

• Summarize data with aggregation queries
• Understand Cloud Firestore billing
• Write-time aggregations
• Distributed counters
• Securely query data
• Connect to the Firestore Emulator and emulator differences
• Firestore Standard Core operations overview
• Firestore Enterprise Native Core/Pipeline overview
• Enterprise Pipeline aggregate stage
• Enterprise pricing examples
• MongoDB compatibility behavior differences
• Managed Firestore export/import
• Firebase Extensions migration guidance, including Stream Firestore to BigQuery
• Firebase JavaScript SDK release notes
• Firebase Admin Node.js SDK release notes