Firestore has two operational modes, and the choice between them is one of those decisions where there is a clear modern default and a clear legacy fallback. Native mode is the new, recommended one. Datastore mode is a compatibility bridge for applications built on the older Google Cloud Datastore service. The Associate Cloud Engineer exam tests this distinction, and once you know the history, the answer is usually obvious. This article covers what each mode is, when each is appropriate, and the framing the exam uses.
It does not cover the deep differences in query semantics, indexing, or pricing between the two modes. The goal is the working understanding the Associate Cloud Engineer exam expects.
Google Cloud Datastore was the original NoSQL document database on GCP. It was built around an entity model that is conceptually similar to a document model, but with its own quirks. Years later, Google released Firestore, which is in many ways a more capable version of Datastore. New data model. New real-time sync. New consistency guarantees.
Rather than force every Datastore user to rewrite their application, Google built Firestore so it could run in two modes. Native mode is the new Firestore experience. Datastore mode is a compatibility layer that makes Firestore behave like the old Datastore, so existing applications keep working without changes.
Once you understand that history, the modes make sense. Native mode is the actual product. Datastore mode is a migration path.
Native mode is what most people mean when they say "Firestore." Documents in collections. Real-time synchronization to clients. Strong consistency. ACID transactions across documents. Mobile and web SDKs that connect directly. This is the mode you would choose for any new project.
The canonical use cases for Firestore, product catalogs, mobile app user profiles, game save states, and ACID transactions like fund transfers, are all native mode use cases. Whenever the Associate Cloud Engineer exam describes a real-time, client-facing application, it is implicitly assuming native mode.
Datastore mode runs Firestore's infrastructure underneath but exposes the older Datastore API and entity model on top. From the application's perspective, it is still talking to Datastore. The data model is entity-based, not document-based. Queries work the same way they did before. Strong consistency and high availability are preserved.
The catch is that you give up the things that make native mode special. No real-time synchronization. No mobile and web SDKs that listen for live updates. The application is what an old Datastore application was, just running on the newer infrastructure.
think of Datastore mode as a stepping stone. It lets an existing Datastore application get the benefits of Firestore's managed infrastructure and scalability without having to rewrite the application. Over time, the application can be modernized to use native mode features. But that is on the application team's schedule, not Google's.
For a brand new project, use native mode. There is no reason to choose Datastore mode for new code unless you have a very specific compatibility constraint, like sharing data with another existing Datastore application.
For an existing Datastore application that is being migrated, use Datastore mode. The application keeps working without changes. You get the underlying improvements of Firestore's infrastructure. You can plan a gradual migration to native mode if and when it makes sense.
You cannot mix the two modes in the same Firestore database. Each Firestore database is either native mode or Datastore mode, and the choice is permanent for that database.
The exam scenarios for this topic are pretty stylized.
If you see "we are starting a new project and need a NoSQL document database," the answer is Firestore in native mode. The exam might just say Firestore without specifying the mode, in which case native is the default.
If you see "we have an existing Google Cloud Datastore application and want to migrate it to Firestore without rewriting it," the answer is Firestore in Datastore mode. The migration framing is the strongest signal.
If you see "we need real-time synchronization to mobile clients," the answer is native mode. Datastore mode does not have real-time sync, so it cannot fit that requirement.
If a question asks which is recommended for new projects, the answer is native mode. The exam framing states this.
The terminology can be confusing because "Datastore" can refer to two things: the original product, and the mode of Firestore that emulates it. The original Datastore product is now effectively retired. New databases are all Firestore, with the choice being which mode to run in.
If a question references "Cloud Datastore" without context, it is usually referring to Datastore mode of Firestore. The standalone Datastore product is no longer the default new option.
Native mode is the modern Firestore, with documents, real-time sync, and ACID transactions. Datastore mode is the bridge for existing Datastore applications. New projects use native mode. Existing Datastore migrations use Datastore mode. The Associate Cloud Engineer exam tests this distinction whenever a scenario involves a Datastore migration or a new client-facing app that needs real-time sync.
My Associate Cloud Engineer course covers Firestore native mode and Datastore mode in the database section, alongside the rest of the GCP database choices the Associate Cloud Engineer exam tests.
