7.2 Firestore Data, Indexes, and Transactions

NoSQL & Object Storage: Firestore, Bigtable, and Cloud Storage

Cloud-native architectures frequently process unstructured media, real-time hierarchical documents, and high-frequency analytical telemetry that exceed the operational boundaries of traditional relational databases. Google Cloud provides three specialized storage solutions for these workloads: Cloud Firestore for flexible serverless document storage, Cloud Bigtable for massive petabyte-scale wide-column time-series analytics, and Cloud Storage (GCS) for durable, highly available object storage. The Google Cloud Professional Cloud Developer exam tests your ability to engineer optimal row keys, configure transactional concurrency, manage data lifecycles, and implement secure direct client file transfers.

---

Cloud Firestore: Architecture and Operating Modes

Cloud Firestore is a fully managed, serverless, document-oriented NoSQL database featuring regional or multi-region replication according to database location, strong consistency, and rich querying capabilities.

Operating Modes: Native Mode vs. Datastore Mode

When creating a Firestore database, you must choose between two mutually exclusive operating modes (mode-conversion eligibility is constrained; do not assume an existing populated database can simply be switched):

The Document-Collection Model & Shallow Queries

In Firestore Native Mode, data is stored in documents, which are organized into collections. Documents can contain nested fields (primitive types, arrays, maps) and can host nested subcollections.

/users (Collection)
  └── user_42 (Document)
        ├── name: "Jane Doe"
        ├── role: "engineer"
        └── /orders (Subcollection)
              └── order_881 (Document)
                    ├── item: "Laptop"
                    └── total: 1200

Exam Trap: Shallow Queries: In Firestore Native Mode, all queries are shallow. Querying a collection retrieves documents within that specific collection only. It never returns documents located in nested subcollections. If your application queries /users, it receives user documents; it will never download the nested /orders documents. To query documents across all orders subcollections simultaneously, you must use a Collection Group Query, which needs a collection-group-scope index appropriate for its filters and ordering; a simple collection-group query does not always require a composite index.

---

Firestore Indexing, Atomic Operations & Security Rules

Single-Field vs. Composite Indexes

• Single-Field Indexes: Firestore automatically maintains ascending and descending indexes for every scalar field in every document, as well as array-contains indexes for array fields. This enables immediate single-clause filtering (e.g., WHERE status == 'active').
• Index Exemptions: Automatic indexing consumes storage and incurs write latency. For fields that contain large strings, frequently updated counters, or unindexed metadata maps, developers should configure Index Exemptions to reduce storage costs and accelerate write throughput.
• Composite Indexes: Complex combinations of filters and ordering can require a composite index; multiple equality filters can sometimes use index merging. When combining equality with inequality operators (<, <=, >, >=) or sort orders (ORDER BY), Firestore requires a composite index:

  Query:   db.collection('tickets').where('status', '==', 'open').orderBy('priority', 'desc')
  Index:   tickets [ status: ASC, priority: DESC ]
  

  If a composite index is missing, Firestore rejects the query and returns an error containing a direct URL to generate the required index in the Google Cloud Console.

Atomic Operations: Transactions vs. Batched Writes

// Atomic Transaction Example (All Reads Must Precede Writes)
await db.runTransaction(async (transaction) => {
  const accountRef = db.collection('accounts').doc('user_123');
  const doc = await transaction.get(accountRef);
  
  if (!doc.exists) throw new Error("Account does not exist!");
  const currentBalance = doc.data().balance;
  if (currentBalance < 500) throw new Error("Insufficient funds!");
  
  // Writes occur after all reads are evaluated
  transaction.update(accountRef, { balance: currentBalance - 500 });
  const logRef = db.collection('audit_logs').doc();
  transaction.set(logRef, { user: 'user_123', amount: 500, timestamp: new Date() });
});

Firestore Security Rules

When mobile or web applications access Firestore directly using client SDKs, Firestore Security Rules enforce authentication, authorization, and data validation:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
      match /orders/{orderId} {
        allow read: if request.auth != null && request.auth.uid == userId;
        allow create, update: if request.auth != null && request.auth.uid == userId
                              && request.resource.data.total > 0;
        allow delete: if request.auth != null && request.auth.uid == userId;
      }
    }
  }
}

Official references checked October 18, 2026: Google Cloud 1.