Firestore for the PDE Exam: Use Cases and Anti-Patterns

Firestore shows up on the Professional Data Engineer exam in a very specific shape. The question describes an application, usually a mobile app, a game, or an e-commerce front end, and asks which Google Cloud database fits. Firestore is the right answer in some of these, and a deliberately wrong answer in others. The trick is recognizing the signals fast, because the exam will pair Firestore against Bigtable, Cloud SQL, Spanner, and BigQuery in the same answer block.

I want to walk through how I read these questions, because once you understand what Firestore is actually optimized for, the anti-patterns become obvious.

What Firestore actually is

Firestore in Native mode is a document-oriented NoSQL database. Data lives in documents, which are grouped into collections, and documents can contain subcollections. It is fully managed and serverless, so there are no nodes to size and no clusters to scale. Throughput grows automatically with traffic.

The features that matter for the Professional Data Engineer exam are these:

• Real-time synchronization. Clients can subscribe to a document or query, and any change is pushed to every connected client. This is the feature that makes Firestore the right answer for chat apps, multiplayer game state, and live dashboards on mobile.
• Mobile and web SDKs with offline support. The Firestore SDK caches data on device, queues writes while offline, and reconciles when the network comes back. No other Google Cloud database ships this out of the box.
• ACID transactions. Firestore supports atomic multi-document transactions. If a question mentions transferring funds, updating inventory while charging a card, or any case where two writes must succeed or fail together, ACID is a green flag.
• Strong consistency. Reads in Firestore reflect the latest committed write. This is different from Bigtable, which is eventually consistent across replicas.
• Multi-region replication. Firestore can replicate across regions for high availability without you wiring up failover.

The fit profile

Put those features together and you get a clear shape. Firestore is built for applications that need highly available, strongly consistent, structured or semi-structured data at scale, with real-time push to clients. When you see that combination of words in a Professional Data Engineer question, Firestore is almost always the intended answer.

Concrete use cases the exam likes:

• Product catalogs with real-time inventory. Each product is a document. When stock drops to zero, every connected client sees it instantly.
• User profiles for mobile apps. Profiles are naturally document-shaped, and the SDK handles offline edits cleanly.
• Game save states. Per-user documents, synced across devices, with offline support so a player on a flight can keep progressing.
• Chat and messaging features. Real-time sync is exactly what chat needs.
• Atomic financial operations. Transferring funds between two accounts in one transaction is the textbook ACID scenario, and Firestore handles it.

The anti-patterns

The harder questions are the ones where Firestore looks plausible but is wrong. Here is the list I memorize before sitting the Professional Data Engineer exam.

Analytics workloads. Firestore is OLTP, not OLAP. If the question describes aggregating millions of rows, computing dashboards, running ad hoc SQL across a fact table, or anything that smells like a data warehouse, the answer is BigQuery. Firestore can return individual documents fast, but it is not designed to scan and group at warehouse scale. If you see GROUP BY across a large dataset in a Firestore question, that is the trap.

Extreme write throughput. Firestore scales well, but if a question explicitly calls out 10 million reads or writes per second, the intended answer is Bigtable. Bigtable is built for that throughput class. The exam uses language like "IoT sensor ingest at massive scale" or "time-series data at millions of writes per second" to push you toward Bigtable.

Unstructured data. Blobs of video, audio, images, large PDFs. That is Cloud Storage. Firestore documents have size limits and are not meant for large opaque payloads.

Semi-structured data without strong consistency requirements. If the question describes wide rows, time-series, or high-throughput key-value access where eventual consistency is fine, Bigtable is cheaper and faster. Firestore is overkill, and at extreme scale it will be the wrong answer even on cost alone.

Relational migrations. If a customer is lifting and shifting MySQL or PostgreSQL, Firestore is not the answer. Cloud SQL preserves the relational model. If they need global scale with relational semantics, Spanner. BigQuery if the workload becomes analytical.

Sub-10ms latency. Firestore is responsive, but for in-memory, sub-millisecond access, Memorystore for Redis is the right tool. Session caches, leaderboards, rate-limit counters all live in Redis, not Firestore.

How I read these on the exam

My quick decision tree:

• Is the workload analytical? BigQuery.
• Is it a relational migration? Cloud SQL or Spanner.
• Does it need extreme write throughput or wide-row time-series? Bigtable.
• Is the data unstructured blobs? Cloud Storage.
• Does it need sub-10ms latency? Redis.
• Is it a mobile, web, or game app that needs real-time sync, offline support, and ACID transactions on structured documents? Firestore.

If you can run that filter quickly, the Firestore questions on the Professional Data Engineer exam stop being ambiguous.

My Professional Data Engineer course covers Firestore alongside every other Google Cloud database in the same exam-focused way, with the decision rules you need when two answers both look plausible.