---
cuppy_hub: gcp
cuppy_path: reference/databases/firestore.md
cuppy_section: docs
cuppy_doc: 8HRA-YX5S
cuppy_doc_uuid: 4654a2db-d9fb-4994-9db6-13ea1899c34d
cuppy_permalink: https://cuppy.io/gcp/d/8HRA-YX5S
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/gcp/docs/reference/databases/firestore
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: 9eccdaca275cf845ccbb02a5794421e55393867ea19ae94aeb4881506e9a5e5d
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# Firestore

## 1. Two modes, one decision

| Mode | What it is for |
|---|---|
| **Firestore** (native mode) | the current product: an enterprise-grade NoSQL database with a **"collection and document data model"**, **real-time updates**, and mobile and web client libraries |
| **Firestore in Datastore mode** | a **backward-compatible** layer for legacy applications, "particularly App Engine apps", that have a "dependency on the Datastore APIs" |

Native mode is the answer for anything new. The page's own framing for it is applications needing "automatic
scaling, high performance, and ease of application development".

**Datastore mode exists for a dependency, not for a capability.** If no code calls the Datastore APIs, there
is no reason to choose it.

## 2. The two features that make native mode a different product

1. **Real-time updates.** A client subscribes and receives changes. That removes a polling loop, or a
   websocket service, or a change-stream consumer, from an architecture.
2. **Mobile and web client libraries.** Clients talk to the database directly, with access decided by security
   rules rather than by an API tier.

Both are reasons a Firestore design often has **fewer components** than the same design on a
database without them — and both are reasons a Firestore application does **not** port cleanly to a database
that lacks them. Note that direct client access is also a security-model decision: the rules are the
authorisation layer, and they are code that needs reviewing.

## 3. MongoDB compatibility

Firestore is described as having **"MongoDB compatibility"**, and that applies to **native Firestore only, not
to Datastore mode**.

For a migration that is a significant row: an application written against MongoDB drivers has a path onto
Firestore that is not a rewrite. The depth of that compatibility is per feature and is not stated on this
page — establish it against the application's actual query and index usage before committing.

## 4. An absence, recorded

**The page does not state whether a database's mode can be changed after creation.** Treat the mode as a
create-time decision and verify the change path from the product's own documentation if a plan depends on it.

A Google Cloud project can hold multiple Firestore databases, so "a second database in the other mode" is
often the practical answer to a mode question — but that is the hub's reading, not a claim from this page.

## 5. For a cross-cloud estimate

Google's own table pairs Firestore with **Amazon DocumentDB and DynamoDB** and with **Azure Cosmos DB**;
Microsoft's pairs **Cloud Firestore** with **Azure Cosmos DB** and the Firebase Realtime Database with the
**Cosmos DB change feed**.

The two-counterpart pattern is informative: Firestore's **document model** maps toward DocumentDB and Cosmos DB
for NoSQL, while its **real-time subscription** maps to a change-feed mechanism that is a separate feature on
both. So a Firestore application moving off Google Cloud needs **two** things on the far side, and the second
one is usually missed. See `guides/parity/databases.md` §4.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->