Firestore

Firestore is a document database. Instead of tables and rows, you store documents — structured objects similar to JSON — inside collections. Documents in the same collection do not need identical fields, so the schema can vary between records and evolve over time.

It is serverless: there is no instance to size or scale. You are billed for the operations you perform and the data you store, and capacity adjusts automatically.

Two properties make Firestore distinctive rather than merely convenient. The first is real-time listeners: a client subscribes to a query and receives updates automatically when matching data changes. Building that with a conventional database means writing a whole synchronisation layer.

The second is offline support. Mobile clients can read and write while disconnected, and changes reconcile when connectivity returns. For mobile applications this removes a substantial amount of difficult work.

• Document — a record holding fields, with a size limit that discourages storing large blobs. Large files belong in Cloud Storage with a reference in the document.
• Collection — a container of documents. Collections can be nested under documents to model hierarchy.
• Query — filters and orders documents. Queries are designed to scale with the size of the result rather than the size of the collection.
• Index — single-field indexes are automatic; queries combining multiple filters and ordering require a composite index you define.
• Real-time listener — a subscription that pushes changes to the client as they happen.
• Security rules — declarative authorisation evaluated on the server, allowing clients to talk to the database directly and safely.
• Transactions and batched writes — atomic operations across multiple documents.

The habits of relational modelling work against you here. In a relational database you normalise and join at read time. In a document database you frequently duplicate data so that a single read returns everything a screen needs.

• Start from the screens in your application and work backwards to the documents.
• Denormalise deliberately — storing an author's display name on each post is normal, not a mistake.
• Keep counters and aggregates as maintained fields rather than computing them by reading many documents.
• Store large binary content in object storage and keep only the reference in the document.

• Mobile applications needing offline capability and automatic synchronisation.
• Collaborative tools where several users see updates live.
• Chat, notifications and activity feeds.
• User profiles, preferences and application state.
• Rapid prototyping where the schema is still changing frequently.