Firestore
Firestore is Google's fully managed serverless NoSQL document database. Choose it for mobile and web applications that need real-time updates, offline sync, and a flexible document schema. Documents are organized into collections. Every field is automatically indexed. Firestore scales from zero to millions of documents with no capacity planning.
Native Mode vs Datastore Mode
Native mode is the current model, supporting real-time listeners, offline sync for mobile clients, and a richer query model. Always use Native mode for new applications. Datastore mode maintains backward compatibility with the legacy Cloud Datastore service and lacks Native mode capabilities.
Data Model
Collections hold documents; documents hold fields and can nest subcollections. Queries are shallow by default — a query on one collection does not scan its subcollections.
Collections contain documents. Documents contain key-value fields, nested objects, and arrays. Documents can have subcollections for hierarchical data. Documents are limited to 1 MiB and a maximum of 40,000 index entries each. In Firestore, store data in the shape it will be read — duplicating some fields across documents is expected and normal.
Consistency and Transactions
Firestore provides strong consistency: reads always return the most recently written data. Multi-document ACID transactions are supported; a transaction must complete within 270 seconds, and its total size is bounded by a 10 MiB request limit rather than a fixed write count.
Queries and Indexing
Firestore indexes every field automatically — single-field queries work without any setup. Queries that filter or order on multiple fields need a composite index that you define in a configuration file and deploy with the application. Without the matching composite index, the query fails at runtime. Firestore does not support full-text search.
Real-Time Listeners
Native mode Firestore pushes document and query changes to connected clients as they happen. Each update generates a billed read operation. Design data models to minimize documents changing per user action.
- Designing data with a normalized relational schema. Firestore is fastest when you store data in the shape it will be read, even if that means duplicating some fields across documents.
- Hitting the 1 MB document limit from unbounded arrays.
- Not planning composite indexes until queries fail in production.
- Using real-time listeners for extremely high-frequency updates.
- Using Firestore for workloads needing SQL joins or analytical aggregations.
- Model data around access patterns.
- Keep documents well under 1 MB.
- Define composite indexes in code and deploy with the application.
- Test security rules with the emulator before deploying.
- Export to BigQuery for analytical queries.
Knowledge Check
What happens if you run a Firestore query that filters on multiple fields but the required composite index does not exist?
- Firestore falls back to a full collection scan and still returns the results, but much more slowly than an indexed query would
- Firestore automatically builds and deploys the required composite index on the first query execution
- The query fails at runtime with an error — composite indexes must be defined and deployed before the query can run
- The query returns partial results that are limited to single-field matches only
Which Firestore mode should you always use for new applications?
- Datastore mode — supports more complex queries than Native mode, including arbitrary joins
- Legacy mode — provides backward compatibility with older Firebase SDKs
- Native mode — supports real-time listeners, offline sync, and a richer query model
- Hybrid mode — combines real-time listeners with SQL-style joins
What is the maximum size of a single Firestore document?
- 10 MB — large enough for most documents, including small embedded media files
- 100 KB — documents are hard-capped this small for performance
- 1 MB — unbounded arrays within a single document can exceed this limit
- 5 MB — matching the limit of a single Cloud Storage object embedded in a document
How does Firestore's consistency model work?
- Eventual consistency — reads may return slightly stale data
- Strong consistency — reads always return the most recently written data
- Session consistency — a client always sees its own writes, but other clients may see stale data
- Causal consistency — reads reflect all writes that causally preceded them
What search capability does Firestore NOT support natively?
- Filtering documents by a single field value
- Ordering results by one field while range-filtering another
- Full-text keyword search across document field values
- Real-time listeners that push changes to clients
You got correct