Cloud Firestore: Data Modeling, Rules & Real-Time

Cloud Firestore

Cloud Firestore is a serverless, automatically scaling document database offered through both Firebase and Google Cloud. Data lives in documents — JSON-like maps of fields — grouped into collections, with subcollections nested under documents. Its signature features are aimed at app developers: client SDKs for web and mobile that read and write directly, real-time listeners that push changes to every connected client, offline persistence on devices, and security rules that decide what each signed-in user may read and write without a custom backend.

Firestore is excellent for user-facing apps with document-shaped data, real-time collaboration, and small teams that want no servers to manage. It is a poor fit for relational reporting, ad hoc analytics, and workloads that need complex joins — and its per-operation pricing rewards careful data modeling.

TL;DR

Data is organized as collections → documents → subcollections; documents are limited to 1 MiB.
Every query is backed by an index; single-field indexes are automatic, composite indexes must be defined.
Real-time listeners (onSnapshot) and offline persistence make collaborative apps simple.
Security rules are the authorization layer when clients access Firestore directly — they are not optional.
There are no joins; model data around queries, using denormalization and aggregation documents.
Pricing is per document read, write, and delete plus storage — query design directly drives cost.

Quick Example

A chat room with the modular web SDK — writing a message and listening to the latest fifty:

Security rules ensure only room members read messages and that users can only post as themselves:

Core Concepts

Data Model

Queries and Indexes

Queries filter and order on fields, with where, orderBy, limit, cursors for pagination, OR queries, in and array-contains operators, and aggregation queries (count, sum, average) that avoid reading every document. Every query is served from an index, so query cost scales with the size of the result, not the size of the collection. Combining filters and ordering on several fields requires a composite index, defined in the console or in firestore.indexes.json; the SDK error message links straight to its creation.

Real Time and Offline

Listeners receive an initial snapshot and then every change that affects the query. Mobile SDKs (and the web SDK when enabled) cache data locally, so apps keep working offline and sync when connectivity returns; local writes appear immediately as pending writes.

Transactions and Batches

Transactions read and then write documents atomically, retrying automatically on contention. Batched writes apply several writes atomically without reads. Use them for counters, transfers, and keeping denormalized copies consistent.

Editions and Modes

Firestore in Native mode is the Firebase-style database described here; Datastore mode serves legacy Cloud Datastore applications without real-time and mobile features. Google also offers an edition with MongoDB-compatible APIs for teams that want MongoDB drivers on Firestore's serverless infrastructure.

Data Modeling

Without joins, you design documents around the screens and queries the app needs:

Denormalize data that is read together, such as storing an author's display name on each post, and update copies with Cloud Functions or batched writes when the source changes.
Use subcollections for unbounded lists (messages, events) instead of growing arrays inside one document.
Keep aggregates — counts, totals — in summary documents updated transactionally, or use aggregation queries.
Avoid hot documents: a single document sustains roughly one write per second; distribute heavy counters across shards.
Avoid sequential indexed values such as timestamps written at very high rates, which concentrate index writes; ramp traffic up gradually on new collections.

See MongoDB Schema Design for the same document-modeling trade-offs in another database.

Cost Awareness

Paginate, limit listeners to what is on screen, avoid re-subscribing on every render, and use aggregation queries instead of reading whole collections to count them.

Best Practices

Write Security Rules Before Shipping

Start from locked-down rules, grant access per path, validate document shape and ownership in rules, and test them with the Firebase Emulator Suite and rules unit tests.

Keep Privileged Logic on the Server

Use Cloud Functions or a backend with the Admin SDK for operations that must not be trusted to clients: payments, role changes, cross-user updates.

Model for Your Queries

List the queries each screen needs before designing collections, and create composite indexes as part of deployment configuration.

Use the Emulator Locally

The Firestore emulator runs locally for development and tests, avoiding costs and protecting production data.

Common Mistakes

Test-Mode Rules in Production

Unbounded Arrays in One Document

Reading Whole Collections to Count

FAQ

What is Cloud Firestore?

A serverless NoSQL document database from Google, available through Firebase and Google Cloud, with client SDKs, real-time listeners, offline support, and security rules for direct client access.

What is the difference between Firestore and the Realtime Database?

Both are Firebase databases with real-time sync. The Realtime Database stores one large JSON tree with simpler querying; Firestore offers collections and documents, richer queries with indexes, better scaling, and stronger structure. Firestore is the usual choice for new projects.

Does Firestore support joins?

No. Data is modeled around queries using denormalization, subcollections, and references resolved by additional reads. Applications that rely heavily on joins and ad hoc reporting are better served by a relational database.

How much does Firestore cost?

Pricing is based on document reads, writes, and deletes, stored data, and network egress, with a free daily quota. Costs depend mostly on how many documents queries and listeners read.

Is Firestore secure if clients access it directly?

Yes, when security rules are written correctly. Rules authenticate requests through Firebase Authentication and authorize every read and write by path and document content. Without proper rules, data is exposed.