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

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.

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.