Google Cloud Firestore with MongoDB compatibility Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Databases

by

Category

Databases

1. Introduction

Firestore with MongoDB compatibility is a managed document database capability in Google Cloud that lets teams use MongoDB tools and drivers against Cloud Firestore while benefiting from Firestore’s fully managed operations, scalability, and Google Cloud integrations.

In simple terms: you keep Firestore as the database, but you can talk to it using familiar MongoDB client patterns (for supported operations), which can reduce migration friction for teams that already standardized on MongoDB libraries.

Technically, Firestore with MongoDB compatibility provides a MongoDB-compatible access path that maps supported MongoDB operations to Firestore’s underlying document model and APIs. This means your application can often keep a MongoDB-style data-access layer while storing data in Firestore—subject to compatibility limits you must validate in the official documentation.

This solves a common problem: teams want Firestore’s managed scaling and Google Cloud-native security/operations, but they also want to reuse existing MongoDB client code, tooling, and developer experience (where compatible), especially for migrations or hybrid portfolios.

Important: Google Cloud product capabilities evolve. Verify the current status (GA/Preview), supported API surface, and limitations in the official docs before committing to a production migration.

2. What is Firestore with MongoDB compatibility?

Official purpose (practical framing)
Firestore with MongoDB compatibility is intended to help teams that are familiar with MongoDB’s developer experience adopt Cloud Firestore by providing MongoDB-compatible connectivity and query behavior for a supported subset of operations, while Firestore remains the underlying managed database.

Core capabilities (what you should expect) – Store and serve application data as documents in Firestore. – Access data using Firestore APIs/SDKs and, when enabled/available, MongoDB-compatible drivers/tools for supported operations. – Use Google Cloud’s security, IAM, logging, monitoring, and governance controls around the database.

Major components – Cloud Firestore database: The managed document database (Native mode). – MongoDB compatibility endpoint / access layer: A compatibility interface that accepts MongoDB-style connections/commands (supported subset) and translates them into Firestore operations (conceptually). – Client tooling: – Firestore SDKs (Admin SDK, server client libraries) – MongoDB drivers and tools (for the compatibility interface), such as common MongoDB language drivers and shells—verify which are supported in official docs.

Service type – Managed NoSQL document database capability in Google Cloud (category: Databases).

Scope and location model – Firestore databases are created per Google Cloud project. – Firestore supports regional and multi-region database locations (availability depends on region). – MongoDB compatibility availability may vary by region and release stage—verify in official docs.

How it fits into the Google Cloud ecosystem Firestore integrates tightly with: – IAM and service accounts for authentication/authorization – Cloud Audit Logs for admin and data access auditing (configurable) – Cloud Monitoring and Cloud Logging for operations – VPC Service Controls for data exfiltration protection (where applicable) – Application platforms such as Cloud Run, GKE, Compute Engine, and serverless workflows

Primary official entry points to start your verification: – Firestore product page: https://cloud.google.com/firestore – Firestore documentation: https://cloud.google.com/firestore/docs – Firestore pricing: https://cloud.google.com/firestore/pricing

3. Why use Firestore with MongoDB compatibility?

Business reasons

  • Faster migration path: If you have apps written for MongoDB drivers, compatibility can reduce rewrites (for supported features).
  • Managed operations: Offload patching, capacity planning, and infrastructure maintenance to Google Cloud.
  • Time-to-market: Build and iterate quickly with a managed database and strong ecosystem integration.

Technical reasons

  • Document model fit: Firestore is designed for document-centric application data (profiles, catalogs, sessions, state).
  • Scalable reads/writes: Firestore is built for high concurrency and elastic scale patterns (within documented limits).
  • API choice: Use Firestore native APIs where you need full feature fidelity, and MongoDB-compatible access where it helps reuse existing code (subject to compatibility).

Operational reasons

  • Observability: Integrates with Cloud Logging/Monitoring; audit trails through Cloud Audit Logs.
  • Automation: Works well with CI/CD and Infrastructure as Code (database provisioning, IAM, policy).
  • Reliability posture: Regional/multi-region placement options for resilience.

Security/compliance reasons

  • IAM-first: Centralized access control via Cloud IAM (and optionally Firebase security rules depending on your usage model).
  • Encryption: Encryption at rest and in transit (verify specifics and configuration options in official docs).
  • Perimeter controls: Potential use of VPC Service Controls to reduce data exfiltration risk.

Scalability/performance reasons

  • Horizontal scaling characteristics: Firestore is designed to scale with application traffic patterns.
  • Optimized for app queries: When modeled properly (indexes, query patterns), Firestore performs well for typical app workloads.

When teams should choose it

Choose Firestore with MongoDB compatibility when: – You want a managed Firestore backend but have existing MongoDB driver-based code you want to reuse. – Your use case matches Firestore strengths: document data, predictable query patterns, high concurrency. – Your MongoDB usage fits within the supported compatibility subset and you’re willing to validate differences.

When teams should not choose it

Avoid or reconsider if: – You require full MongoDB feature parity (advanced aggregation pipelines, specialized operators, server-side JS, or niche behaviors)—verify compatibility limits first. – Your workload is strongly relational (complex joins/transactions across many entities) and fits better in Cloud SQL, AlloyDB, or Spanner. – You require strict, large-scale analytical queries; consider BigQuery or an analytical datastore.

4. Where is Firestore with MongoDB compatibility used?

Industries

  • SaaS and B2B platforms (tenant metadata, app configuration)
  • Retail and e-commerce (catalogs, carts, user profiles)
  • Media and gaming (player state, leaderboards, content metadata)
  • Financial services (non-ledger application state, session data—ensure compliance alignment)
  • Healthcare (non-clinical app data; ensure HIPAA/BAA requirements and controls)

Team types

  • Full-stack product engineering teams
  • Platform/DevOps teams standardizing data services
  • Mobile/backend teams using document models
  • SRE/operations teams that need managed reliability with good observability

Workloads

  • User profile and preference stores
  • App configuration and feature flags (when designed carefully)
  • Content metadata and tagging
  • Event state and workflow state
  • Session and device state

Architectures

  • Serverless microservices (Cloud Run + Firestore)
  • Kubernetes-based services (GKE + Firestore)
  • Event-driven systems (Pub/Sub + Cloud Run/Functions + Firestore)
  • Hybrid: some services use Firestore native SDK; others use MongoDB drivers via compatibility where supported

Real-world deployment contexts

  • Production: Multi-region or regional deployments with controlled IAM, audit logs, backups/exports (verify tooling), and runbooks.
  • Dev/test: Low-cost environments with stricter quotas, smaller datasets, and automated teardown.

5. Top Use Cases and Scenarios

Below are realistic scenarios where Firestore with MongoDB compatibility can be a strong fit—assuming the MongoDB compatibility layer supports the specific operations you rely on.

1) MongoDB-to-Google Cloud migration with minimal code change

  • Problem: Existing services use MongoDB drivers and data-access patterns; rewrite cost is high.
  • Why this fits: MongoDB compatibility can preserve client-side patterns while moving storage to Firestore.
  • Scenario: A Node.js API using the MongoDB driver migrates core collections (users, orgs) to Firestore while keeping the same repository layer for supported queries.

2) New greenfield service for a MongoDB-native team

  • Problem: Team is skilled in MongoDB tooling; wants managed database on Google Cloud.
  • Why this fits: Familiar interfaces reduce ramp-up while Firestore provides managed ops.
  • Scenario: A new “notifications” microservice uses MongoDB-style inserts/queries (supported subset) while leveraging Cloud Logging/Monitoring for ops.

3) Multi-tenant SaaS configuration store

  • Problem: Need fast reads by tenant/app; flexible schema.
  • Why this fits: Document model fits variable configuration structures; compatibility may allow existing MongoDB config service code reuse.
  • Scenario: Tenant config documents keyed by tenantId, retrieved frequently by Cloud Run services.

4) User profile service with evolving schema

  • Problem: Profiles evolve rapidly; relational migrations slow teams down.
  • Why this fits: Document schema flexibility; compatibility helps reuse existing MongoDB profile-service code.
  • Scenario: Store profile, preferences, and AB experiment assignments per user document.

5) Product catalog and search pre-index store

  • Problem: Store product metadata; push to a search engine separately.
  • Why this fits: Firestore stores canonical product docs; pipelines publish to Vertex AI Search/Elastic/OpenSearch.
  • Scenario: A Cloud Run job reads updated products and syncs them to a search index.

6) IoT device state and shadow documents

  • Problem: Devices send periodic state updates; dashboards need current state.
  • Why this fits: Document-per-device model; high concurrency patterns when designed for distribution.
  • Scenario: Each device writes to devices/{deviceId}; dashboards read by device group.

7) Content management metadata store

  • Problem: CMS needs flexible metadata: tags, locales, publishing flags.
  • Why this fits: Document model; compatibility may help reuse existing MongoDB-based CMS backends.
  • Scenario: Content docs store metadata; media blobs are in Cloud Storage.

8) Per-user session store (stateful workloads)

  • Problem: Maintain session state for web apps; need durability.
  • Why this fits: Document store is a common fit (but validate latency and TTL needs).
  • Scenario: Session documents keyed by sessionId, with expiration handled by application logic (verify TTL options if needed).

9) Workflow state for distributed orchestration

  • Problem: Track step-by-step state for long-running processes.
  • Why this fits: Document updates represent workflow transitions; easy to resume.
  • Scenario: Order fulfillment service updates orders/{id} with state history.

10) Mobile/backend synchronization backend (Firestore-native strength)

  • Problem: Need near-real-time sync patterns for apps.
  • Why this fits: Firestore is often used for app sync patterns; MongoDB compatibility can help backend services written around MongoDB.
  • Scenario: Mobile clients use Firestore SDK; backend batch jobs use MongoDB-compatible reads/writes (supported subset).

6. Core Features

Note: Firestore capabilities are well-documented; MongoDB compatibility introduces a second access model. Always validate feature parity and supported operations in the official MongoDB compatibility documentation for Firestore (verify in official docs).

1) Managed document database (Cloud Firestore)

  • What it does: Stores JSON-like documents in collections.
  • Why it matters: Natural fit for app entities; flexible schema.
  • Practical benefit: Faster iteration and fewer schema migrations than strict relational models.
  • Limitations/caveats: Data modeling is critical; certain query patterns require indexes; avoid unbounded fan-out patterns.

2) MongoDB-compatible connectivity (supported subset)

  • What it does: Allows supported MongoDB drivers/tools to perform operations against Firestore.
  • Why it matters: Reduces migration effort and retraining costs.
  • Practical benefit: Keep parts of your application’s DAO/repository layer intact.
  • Limitations/caveats: Not full MongoDB parity; aggregation and advanced features may not match. Verify supported commands/operators.

3) Indexing and query support (Firestore model)

  • What it does: Supports indexed queries on fields; composite indexes for multi-field queries.
  • Why it matters: Predictable performance when query patterns align with indexes.
  • Practical benefit: Fast lookups and filtered queries for app workloads.
  • Limitations/caveats: Some query combinations require composite indexes; certain query patterns are constrained.

4) Regional and multi-region placement

  • What it does: Lets you choose a database location strategy.
  • Why it matters: Latency, availability, and disaster recovery characteristics depend on placement.
  • Practical benefit: Multi-region can improve resilience; regional can reduce latency to a primary region.
  • Limitations/caveats: Availability and pricing can differ by location; verify supported regions.

5) IAM-based access control (Google Cloud)

  • What it does: Controls who/what can access Firestore via IAM roles.
  • Why it matters: Centralized security governance across Google Cloud.
  • Practical benefit: Consistent access patterns with service accounts and workload identity.
  • Limitations/caveats: Fine-grained per-document authorization is usually handled at the application layer or via Firebase Security Rules (depending on how you access Firestore).

6) Audit logging (Cloud Audit Logs)

  • What it does: Records administrative actions and (optionally/configurably) data access.
  • Why it matters: Compliance, forensics, and change tracking.
  • Practical benefit: Trace who changed IAM, who accessed data, and from where.
  • Limitations/caveats: Data access logs can increase logging volume and cost; configure carefully.

7) Observability (Cloud Monitoring + Logging)

  • What it does: Exposes metrics and logs for performance and error monitoring.
  • Why it matters: Production operations need SLOs, alerting, and troubleshooting.
  • Practical benefit: Alert on error rates, latency, throttling, and quota issues.
  • Limitations/caveats: Metrics granularity and available dashboards vary; verify current metrics.

8) Integration with serverless and containers

  • What it does: Works with Cloud Run, Cloud Functions, GKE, Compute Engine.
  • Why it matters: Common app hosting patterns on Google Cloud.
  • Practical benefit: Simple connection model; no database servers to manage.
  • Limitations/caveats: Ensure appropriate auth, concurrency settings, and retry logic to avoid hot spots and cost spikes.

9) Data export/import patterns (operational tooling)

  • What it does: Firestore supports managed export/import workflows (verify current tooling and best practices).
  • Why it matters: Backups, migrations, and disaster recovery.
  • Practical benefit: Periodic exports to Cloud Storage can support recovery.
  • Limitations/caveats: RPO/RTO and restore steps must be tested; export frequency affects cost.

7. Architecture and How It Works

High-level service architecture

At its core: – Your application sends requests using either: – Firestore SDKs / REST APIs, or – MongoDB-compatible clients (where enabled and supported) – Firestore enforces authentication (IAM/service accounts, depending on access path), and applies authorization. – Firestore executes document reads/writes/queries with appropriate indexing. – Operations emit logs/metrics to Cloud Logging/Monitoring and audit trails to Cloud Audit Logs.

Request/data/control flow (conceptual)

  1. Client authenticates (service account, workload identity, or user identity depending on app design).
  2. Client sends query/write: – Native: Firestore client library call – Compatible: MongoDB driver command mapped into Firestore operations
  3. Firestore processes request, checks permissions/quota, reads/writes indexed data.
  4. Response returned to client.
  5. Logs/metrics/audit events emitted.

Integrations with related Google Cloud services

  • Cloud Run / GKE / Compute Engine: host APIs and workers.
  • Secret Manager: store connection info and credentials (especially if using MongoDB-style connection strings).
  • Cloud KMS: customer-managed encryption keys (CMEK) where supported—verify Firestore CMEK support and configuration in official docs.
  • Pub/Sub: event-driven updates; write-side pipelines.
  • Cloud Storage: export/import, backups, analytics staging.
  • BigQuery: analytics via export/ETL (verify best approach for Firestore data).

Dependency services

  • Firestore depends on Google-managed infrastructure; you primarily manage:
  • Project configuration
  • IAM
  • Networking access to Google APIs
  • Quotas and budgets
  • App-side reliability and schema/modeling

Security/authentication model

  • Cloud IAM: Roles assigned to users/service accounts for database access.
  • Service accounts: Recommended for workloads (Cloud Run, GKE).
  • MongoDB compatibility auth: Verify in official docs. Prefer identity-based auth (IAM/workload identity) over long-lived secrets whenever possible.

Networking model

  • Firestore is accessed via Google-managed endpoints.
  • From VPC-based workloads you typically use:
  • Private Google Access (to reach Google APIs privately) and/or
  • VPC Service Controls (to reduce exfiltration risk)
  • If MongoDB compatibility uses distinct endpoints/ports, validate firewall and egress policies accordingly (verify in official docs).

Monitoring/logging/governance

  • Cloud Monitoring: track latency, errors, throughput, quota usage.
  • Cloud Logging: capture application logs and Firestore-related logs.
  • Cloud Audit Logs: record admin changes and optionally data access.
  • Budgets & alerts: protect against runaway read/write costs.

Simple architecture diagram

flowchart LR
  A[App (Cloud Run / GKE / VM)] -->|Firestore SDK or REST| F[Cloud Firestore]
  A -->|MongoDB driver (compatibility)| M[Firestore with MongoDB compatibility]
  M --> F
  F --> L[Cloud Logging / Cloud Monitoring]
  F --> A2[Cloud Audit Logs]

Production-style architecture diagram

flowchart TB
  subgraph VPC[Customer VPC]
    CR[Cloud Run / GKE Services]
    J[Batch Worker / Scheduler]
    SM[Secret Manager]
  end

  subgraph GC[Google Cloud Managed Services]
    FS[(Cloud Firestore Database)]
    MAPI[Firestore with MongoDB compatibility]
    PUB[Pub/Sub]
    LOG[Cloud Logging]
    MON[Cloud Monitoring]
    AUD[Cloud Audit Logs]
    GCS[Cloud Storage (exports/backups)]
    BQ[BigQuery (analytics)]
  end

  CR -->|IAM auth| FS
  CR -->|MongoDB driver (supported)| MAPI --> FS
  J --> FS
  CR --> SM
  J --> SM

  CR --> PUB
  PUB --> J

  FS --> LOG
  FS --> MON
  FS --> AUD
  FS -->|export| GCS --> BQ

8. Prerequisites

Google Cloud account and project

  • A Google Cloud account with an active billing account
  • A Google Cloud project where you will enable Firestore

Permissions / IAM roles

You need permissions to: – Enable APIs – Create and manage Firestore databases – Create service accounts and keys (or configure workload identity)

Common roles (verify least-privilege for your org): – roles/owner (broad; not recommended long-term) – roles/editor (broad) – Firestore/Datastore roles (names can vary by API surface; verify): – roles/datastore.user – roles/datastore.viewer – roles/datastore.owner (use carefully)

Firestore IAM uses the Datastore permission namespace in many places. Verify current recommended roles in the Firestore IAM documentation: https://cloud.google.com/firestore/docs/security/iam

Billing requirements

  • Billing must be enabled; Firestore usage incurs charges based on operations and storage (see pricing section).

CLI/SDK/tools needed

  • gcloud CLI: https://cloud.google.com/sdk/docs/install
  • Node.js 18+ (for the sample app) or your preferred runtime
  • Optional (for MongoDB compatibility testing):
  • mongosh or MongoDB driver tooling if supported (verify versions supported)

Region availability

  • Choose a Firestore location (regional or multi-region) that meets your latency/compliance needs.
  • MongoDB compatibility availability may be limited by region or release stage—verify in official docs.

Quotas/limits

  • Firestore has quotas and limits around operations, indexes, document sizes, and throughput.
  • Review quotas before load testing: https://cloud.google.com/firestore/quotas

Prerequisite services

  • Firestore API enablement
  • If using Cloud Run: Cloud Run API enablement
  • If using Secret Manager: Secret Manager API enablement

9. Pricing / Cost

Firestore with MongoDB compatibility is priced according to Cloud Firestore’s pricing dimensions, because Firestore remains the underlying database. MongoDB-compatible operations (where available) ultimately translate into Firestore operations and can drive the same billing meters.

Always confirm pricing in: – Official Firestore pricing page: https://cloud.google.com/firestore/pricing – Google Cloud Pricing Calculator: https://cloud.google.com/products/calculator

Pricing dimensions (typical for Firestore)

Pricing varies by location and can change. Common pricing meters include: – Document reads – Document writes – Document deletes – Storage (GB-month) – Network egress (data leaving Google Cloud/region) – Possibly index storage overhead (depending on Firestore behavior and index requirements)

Verify current SKUs and what counts as a read/write for your access method (native SDK vs MongoDB compatibility) in official docs.

Free tier

Firestore historically has a free tier (limits apply and vary by plan/location). Verify current free tier details on the official pricing page.

Primary cost drivers

  • High read rates (especially chatty endpoints or N+1 query patterns)
  • High write rates (event ingestion, telemetry, frequent state updates)
  • Large documents and large index footprints
  • Query patterns that scan more documents than intended
  • Excessive retries from clients (misconfigured backoff)
  • Data egress to other clouds or the public internet

Hidden or indirect costs

  • Logging costs if you enable verbose data access audit logs
  • Compute costs for Cloud Run/GKE/VMs running your services
  • Data pipeline costs (Pub/Sub, Dataflow, BigQuery) if you export/ETL Firestore data
  • Backups/exports stored in Cloud Storage

Network/data transfer implications

  • Calls from Cloud Run/GKE in the same region often reduce latency, but billing is still based on Firestore pricing meters plus any applicable network charges.
  • Cross-region access can increase latency and may add network egress charges depending on architecture and routing.

How to optimize cost

  • Model your data for single-document reads where possible.
  • Avoid unbounded queries; use indexed lookups.
  • Cache aggressively where safe (Cloud CDN / Memorystore / in-service caching).
  • Use budgets and alerts; cap unexpected growth with rate limiting.
  • Reduce log volume (sampling, severity filtering).
  • Batch operations where supported by your client/library (verify).

Example low-cost starter estimate (how to think about it)

A dev/test environment typically has: – Small dataset (< a few GB) – Low daily traffic – Minimal exports/logging

Estimate by: 1. Forecast reads/writes per day. 2. Multiply by pricing per 100K/1M operations (varies by region). 3. Add storage GB-month. 4. Add egress if data leaves the region or internet.

Use the pricing calculator for concrete numbers: https://cloud.google.com/products/calculator

Example production cost considerations

In production, costs often come from: – High QPS read endpoints (feeds, profiles, catalogs) – Frequent writes (events, device state) – Index overhead due to many composite indexes – Multi-region placement (if priced differently) – Audit logging volume

A practical approach: – Load test with representative queries. – Track real read/write counts per request. – Create dashboards for ops/minute and cost forecasting. – Add budgets and anomaly detection.

10. Step-by-Step Hands-On Tutorial

This lab focuses on creating a Firestore database, writing/reading documents using the Firestore Node.js client, and then (optionally) validating MongoDB compatibility if your project has access to that feature.

Objective

  • Provision Cloud Firestore in a Google Cloud project.
  • Run a small Node.js service to write and query documents.
  • (Optional) Connect using MongoDB tooling if Firestore with MongoDB compatibility is enabled for your project/region.

Lab Overview

You will: 1. Create/select a Google Cloud project and enable required APIs. 2. Create a Firestore database (choose a location). 3. Create a service account and run a local Node.js script that writes/reads data. 4. (Optional) Test MongoDB-compatible connectivity using a MongoDB driver or shell. 5. Clean up resources.

Step 1: Create or select a Google Cloud project

  1. Open Cloud Shell (recommended) or use your local terminal with gcloud installed.
  2. Set your project variables:
export PROJECT_ID="YOUR_PROJECT_ID"
gcloud config set project "$PROJECT_ID"
  1. Verify:
gcloud config get-value project

Expected outcome: Your terminal shows the correct PROJECT_ID.

Step 2: Enable required APIs

Enable Firestore and (optional) supporting APIs:

gcloud services enable firestore.googleapis.com
gcloud services enable secretmanager.googleapis.com

If you plan to deploy to Cloud Run later:

gcloud services enable run.googleapis.com

Expected outcome: APIs enable successfully (may take 30–120 seconds).

Verification:

gcloud services list --enabled --filter="name:firestore.googleapis.com"

Step 3: Create a Firestore database (Native mode)

Firestore requires choosing a location. You can do this via Console or gcloud (availability varies).

Console approach (most reliable): 1. Go to Firestore in Google Cloud Console: https://console.cloud.google.com/firestore 2. Click Create database 3. Choose Native mode 4. Select a location (regional or multi-region) 5. Create the database

Expected outcome: Firestore database is created and visible in the Console.

Verification: – In the Firestore UI, you should see an empty database ready for collections/documents.

If you must automate via CLI, verify current gcloud support for Firestore database creation in official docs or gcloud firestore --help, as CLI capabilities can change.

Step 4: Create a service account for local testing

For local development, you can use a service account key. In production, prefer Workload Identity (no downloadable keys).

  1. Create a service account:
export SA_NAME="fs-mongo-compat-lab"
gcloud iam service-accounts create "$SA_NAME" \
  --display-name="Firestore MongoDB compatibility lab"
  1. Grant Firestore access (choose least privilege appropriate for the lab). For a read/write lab:
export SA_EMAIL="${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"
gcloud projects add-iam-policy-binding "$PROJECT_ID" \
  --member="serviceAccount:${SA_EMAIL}" \
  --role="roles/datastore.user"
  1. Create a key file (store securely; delete after lab):
gcloud iam service-accounts keys create "./sa-key.json" \
  --iam-account="${SA_EMAIL}"

Expected outcome: sa-key.json is created locally.

Verification:

ls -l sa-key.json

Step 5: Build and run a Node.js script using Firestore SDK

This script will: – Create a users collection – Insert a couple documents – Query by a field

  1. Create a folder and initialize Node.js:
mkdir firestore-mongo-compat-lab
cd firestore-mongo-compat-lab
npm init -y
  1. Install the Firestore client:
npm install @google-cloud/firestore
  1. Create index.js:
const { Firestore } = require("@google-cloud/firestore");

async function main() {
  // Uses GOOGLE_APPLICATION_CREDENTIALS for auth
  const db = new Firestore({
    projectId: process.env.GOOGLE_CLOUD_PROJECT,
  });

  const users = db.collection("users");

  // Write documents
  await users.doc("u1").set({
    userId: "u1",
    email: "alex@example.com",
    plan: "free",
    createdAt: new Date().toISOString(),
  });

  await users.doc("u2").set({
    userId: "u2",
    email: "sam@example.com",
    plan: "pro",
    createdAt: new Date().toISOString(),
  });

  // Query documents
  const snap = await users.where("plan", "==", "pro").get();

  console.log(`Found ${snap.size} pro user(s).`);
  snap.forEach((doc) => console.log(doc.id, doc.data()));
}

main().catch((err) => {
  console.error(err);
  process.exitCode = 1;
});
  1. Export environment variables and run:
export GOOGLE_APPLICATION_CREDENTIALS="$PWD/../sa-key.json"
export GOOGLE_CLOUD_PROJECT="$PROJECT_ID"
node index.js

Expected outcome: – Output like: – Found 1 pro user(s). – followed by the u2 document content.

Verification (Console): 1. Go to Firestore Data view: https://console.cloud.google.com/firestore/databases 2. Open your database and confirm the users collection exists with documents u1 and u2.

Step 6 (Optional): Validate MongoDB compatibility connectivity

This step depends on whether Firestore with MongoDB compatibility is available/enabled in your project and region.

6A) Confirm feature availability

  • Check Firestore docs and your Console Firestore page for a section related to MongoDB compatibility.
  • If the feature is in Preview or allowlisted, you may need to request access.

Expected outcome: You either (a) see configuration details for MongoDB compatibility, or (b) confirm it is not available for your project/region yet.

6B) Obtain connection details (from Console / docs)

If available, you typically retrieve: – A MongoDB-style connection string/endpoint – The authentication method (IAM-based, user/password, certificates, etc.—verify) – Any required CA certificates or TLS settings

Store sensitive strings in Secret Manager if you plan to reuse them.

6C) Test with mongosh (example pattern)

If mongosh is supported and you have a connection string, the command typically looks like:

mongosh "YOUR_MONGODB_COMPAT_CONNECTION_STRING"

Then you might try basic commands (supported subset only):

show dbs
use appdb
show collections
db.users.find({ plan: "pro" }).limit(5)

Expected outcome: You can list/query the users data (or the Firestore-mapped equivalent) depending on how collections/databases are represented in the compatibility layer.

If data does not appear as expected, verify the mapping model (database/collection naming, namespaces) in the official Firestore with MongoDB compatibility documentation.

6D) Test with a MongoDB Node.js driver (example pattern)

Install the driver:

npm install mongodb

Create mongo-test.js:

const { MongoClient } = require("mongodb");

async function main() {
  const uri = process.env.MONGO_URI; // set this from your Console-provided connection string
  const client = new MongoClient(uri);

  await client.connect();

  // The database/collection naming depends on the compatibility layer mapping.
  // Verify in official docs how Firestore collections map into MongoDB namespaces.
  const db = client.db("appdb");
  const users = db.collection("users");

  const docs = await users.find({ plan: "pro" }).limit(10).toArray();
  console.log("Pro users:", docs);

  await client.close();
}

main().catch((e) => {
  console.error(e);
  process.exitCode = 1;
});

Run:

export MONGO_URI="YOUR_MONGODB_COMPAT_CONNECTION_STRING"
node mongo-test.js

Expected outcome: The script prints matching documents if the mapping and query are supported.

Validation

Use this checklist: – Firestore database exists in the selected location. – users/u1 and users/u2 exist in Firestore. – The Node.js Firestore script prints Found 1 pro user(s). – (Optional) MongoDB compatibility connection succeeds and basic query returns results (if the feature is enabled and supports the query).

Troubleshooting

Problem: PERMISSION_DENIED or The caller does not have permission – Confirm the service account has roles/datastore.user (or appropriate Firestore roles). – Confirm GOOGLE_APPLICATION_CREDENTIALS points to the right key. – Confirm you are using the correct PROJECT_ID.

Problem: Firestore database not created / prompts to create – Firestore requires database initialization in Console (or supported CLI flow). – Ensure you selected Native mode and completed creation.

Problem: Quota exceeded / throttling – Review quotas: https://cloud.google.com/firestore/quotas – Reduce parallelism, add exponential backoff, and avoid hot documents.

Problem (Optional MongoDB compatibility): Connection refused / TLS errors – Verify endpoint, port, and TLS requirements from official docs. – Ensure outbound firewall rules allow egress if your environment restricts traffic. – Confirm you’re using supported client versions (verify).

Problem (Optional MongoDB compatibility): Data mapping confusion – Validate how Firestore collections/documents map to MongoDB databases/collections. – Confirm whether the compatibility layer uses a specific database name or namespace rules.

Cleanup

  1. Delete the service account key file locally:
rm -f ../sa-key.json
  1. Delete the service account (optional):
gcloud iam service-accounts delete "$SA_EMAIL" --quiet
  1. If this was a dedicated lab project, delete the project (most complete cleanup):
gcloud projects delete "$PROJECT_ID" --quiet

Deleting the project removes all resources and stops billing for them (after Google Cloud finalizes deletion).

11. Best Practices

Architecture best practices

  • Design for access patterns: In document databases, modeling is query-driven. Define your top queries first.
  • Avoid hot spots: Distribute writes across many documents/keys; avoid single-document counters updated at high frequency.
  • Bounded queries only: Always use filters and indexes to prevent scanning large datasets unintentionally.
  • Separate transactional vs analytical: Use Firestore for operational workloads; export to BigQuery for analytics.

IAM/security best practices

  • Least privilege: Assign only the roles needed (viewer vs user vs admin).
  • Prefer workload identity: For GKE/Cloud Run, prefer identity federation over downloaded keys.
  • Separate environments: Use separate projects for dev/test/prod; separate service accounts per environment.

Cost best practices

  • Measure reads/writes per request: Instrument your application to estimate cost per endpoint.
  • Cache: Reduce repeated reads (in-memory caching, CDN where appropriate).
  • Budget alerts: Set budgets and alerts; treat unexpected spikes as incidents.

Performance best practices

  • Index deliberately: Create composite indexes only for real queries; remove unused ones.
  • Keep documents small: Avoid extremely large documents; split into subcollections or related documents as needed.
  • Batch where supported: Use batch writes/transactions appropriately (verify limits).

Reliability best practices

  • Choose location strategically: Place Firestore near your compute and users; use multi-region when needed for resilience.
  • Retry safely: Implement exponential backoff; ensure idempotency where possible.
  • Test restores: If you rely on export/import for recovery, test RTO/RPO in practice.

Operations best practices

  • Dashboards: Track error rates, latency, throttling/quota events, and operation counts.
  • Runbooks: Document incident steps for quota spikes, auth failures, and index issues.
  • Change control: Treat index changes and IAM changes as controlled deployments.

Governance/tagging/naming best practices

  • Use consistent naming for:
  • projects (prod-app1, dev-app1)
  • service accounts (app1-api-prod-sa)
  • secrets (firestore-mongo-uri-prod)
  • Use labels/tags on compute resources (Cloud Run services, GKE namespaces) to allocate costs and ownership.

12. Security Considerations

Identity and access model

  • Firestore integrates with Cloud IAM:
  • Human access via Google identities and groups
  • Workload access via service accounts
  • For MongoDB compatibility:
  • Verify authentication options (IAM-based auth is preferred; if passwords/certs are used, rotate and store in Secret Manager).

Encryption

  • Encryption in transit via TLS for Google APIs.
  • Encryption at rest is standard for Google Cloud managed services.
  • If you require CMEK (customer-managed keys), verify Firestore CMEK support and configuration: start at https://cloud.google.com/firestore/docs

Network exposure

  • Firestore is reached via Google-managed endpoints.
  • Reduce exposure by:
  • Running workloads in private networks and using Private Google Access
  • Applying VPC Service Controls where appropriate (verify Firestore support and constraints)
  • If MongoDB compatibility requires specific endpoints/ports, ensure your egress is restricted and monitored.

Secrets handling

  • Avoid embedding credentials in code or container images.
  • Use Secret Manager for connection strings or certificates (if applicable).
  • Rotate secrets and restrict Secret Manager access via IAM.

Audit/logging

  • Enable Admin Activity audit logs (typically enabled by default).
  • Consider enabling Data Access logs for sensitive environments, but budget for log volume and cost.
  • Export logs to a central logging project/SIEM if required.

Compliance considerations

  • Data residency: choose regional/multi-region based on residency requirements.
  • Access control: use groups, least privilege, separation of duties.
  • Retention: configure log retention and data export retention policies.

Common security mistakes

  • Using long-lived service account keys in production.
  • Granting overly broad roles (Owner, Editor) to applications.
  • Allowing unrestricted egress from workloads that access sensitive databases.
  • Not monitoring audit logs or missing alerting on IAM changes.

Secure deployment recommendations

  • Use Cloud Run/GKE with workload identity.
  • Enforce org policies (domain restricted sharing, disable service account key creation where possible).
  • Add budget alerts and anomaly detection on operations/egress.

13. Limitations and Gotchas

Always validate the latest constraints in official docs; database services evolve quickly.

Compatibility limitations (MongoDB)

  • Not full MongoDB parity: Expect unsupported commands/operators and behavioral differences.
  • Aggregation/query differences: Advanced MongoDB aggregations may not be supported or may behave differently.
  • Tooling/version constraints: Only certain driver versions/tools may be supported—verify.

Firestore modeling constraints

  • Query patterns are constrained by indexes and Firestore query rules (ordering, inequality filters, composite indexes).
  • Document size and write frequency limits can impact design.
  • Hot documents and hot collections can cause throttling.

Quotas and rate limits

  • Firestore has documented quotas (operations per second, index builds, etc.). Review: https://cloud.google.com/firestore/quotas

Regional constraints

  • Not all regions support all features.
  • Multi-region vs regional impacts latency, resilience, and potentially cost.

Pricing surprises

  • A “small” query can become expensive if it reads many documents.
  • Indexes can increase storage usage.
  • Excessive retries can multiply read/write counts.

Operational gotchas

  • Index build delays can affect new query rollouts.
  • If you enable verbose audit logging, log ingestion costs can rise quickly.
  • Backup/export workflows must be tested; do not assume restores are instantaneous.

Migration challenges

  • Data type mapping differences (MongoDB BSON vs Firestore field types).
  • Query semantics differences.
  • Application-level authorization patterns may need redesign.

Vendor-specific nuances

  • IAM integration is a strength, but it’s not identical to MongoDB’s native auth models.
  • Operational behavior (quotas, throttling) differs from self-managed MongoDB and must be planned for.

14. Comparison with Alternatives

Firestore with MongoDB compatibility sits at the intersection of: – Firestore as a managed document database – MongoDB developer ergonomics (where compatible)

Key comparisons (high level)

  • Firestore (native SDK): Full Firestore capability; best for Firestore-first designs.
  • MongoDB Atlas on Google Cloud: Full MongoDB feature set; managed by MongoDB; different cost/ops model.
  • Cloud SQL / AlloyDB: Relational workloads with SQL, joins, transactional modeling.
  • Cloud Spanner: Globally scalable relational database with strong consistency and SQL.
  • Bigtable: Wide-column NoSQL for time-series/large scale key-value patterns.
  • Self-managed MongoDB on GKE/VMs: Maximum control; highest ops burden.

Comparison table

Option Best For Strengths Weaknesses When to Choose
Firestore with MongoDB compatibility (Google Cloud) Teams wanting Firestore managed ops with MongoDB-like access Managed scaling/ops, Google Cloud IAM/logging, potential code reuse via MongoDB drivers (supported subset) Compatibility gaps vs MongoDB; must validate supported features Migration/hybrid portfolios where supported MongoDB operations are sufficient
Cloud Firestore (native access) Firestore-first application development Full Firestore features, best-supported client libraries Requires adopting Firestore API patterns New apps built around Firestore query/index model
MongoDB Atlas (on Google Cloud) Full MongoDB feature parity needs Full MongoDB API, mature tooling/ecosystem Different billing and operations model; less “Google-native” IAM integration You need MongoDB features that compatibility layers don’t support
Cloud SQL / AlloyDB Relational OLTP apps SQL, joins, constraints, familiar RDBMS patterns Vertical scaling limits (relative to Spanner), schema rigidity Strong relational modeling and transactions are primary
Cloud Spanner Globally consistent relational at scale Horizontal scale, strong consistency, SQL Data modeling and cost complexity Global apps needing strong consistency and scale
Bigtable Time-series, high-throughput key/value Very high scale, low-latency key lookups Not a document DB; limited query flexibility Telemetry/time-series and large key-range workloads
Self-managed MongoDB on GKE/VM Custom MongoDB deployments Total control, custom extensions High operational overhead, patching, backups, scaling complexity You need custom control and accept ops burden

15. Real-World Example

Enterprise example: Multi-tenant SaaS modernization on Google Cloud

  • Problem: A large enterprise has dozens of internal services using MongoDB drivers. They want to standardize on Google Cloud managed services, strengthen IAM governance, and reduce operational toil.
  • Proposed architecture:
  • Cloud Run microservices for APIs
  • Firestore as the operational document store
  • Firestore with MongoDB compatibility for select services where rewrites are costly
  • Pub/Sub for async workflows
  • Cloud Logging/Monitoring with centralized dashboards
  • VPC Service Controls for data perimeter (where applicable)
  • Why this service was chosen:
  • Firestore provides managed scaling and strong Google Cloud integration.
  • MongoDB compatibility reduces migration risk for services that can fit within supported operations.
  • Expected outcomes:
  • Reduced operational overhead (no cluster patching/ops).
  • Faster migration timelines for compatible services.
  • Stronger governance (IAM, audit logs, centralized monitoring).

Startup/small-team example: Fast iteration backend with MongoDB familiarity

  • Problem: A startup team knows MongoDB well and wants to ship quickly on Google Cloud without running database servers.
  • Proposed architecture:
  • Single Cloud Run backend
  • Firestore storing user profiles and app data
  • Optional MongoDB compatibility for quick integration with existing Node.js MongoDB-based repository code (supported subset)
  • Secret Manager for configuration and secrets
  • Why this service was chosen:
  • Managed database reduces ops load.
  • Team can reuse familiar tooling where supported.
  • Expected outcomes:
  • Rapid iteration with fewer infrastructure responsibilities.
  • Predictable ops via Google Cloud monitoring and IAM controls.

16. FAQ

1) Is “Firestore with MongoDB compatibility” the same as MongoDB?
No. Firestore is the underlying database. MongoDB compatibility is an access/compatibility layer for supported operations. Expect differences; validate feature support.

2) Do I get full MongoDB API compatibility?
Not necessarily. Compatibility layers typically support a subset. Verify supported commands/operators and behavior in official docs before migrating.

3) Does this replace using Firestore SDKs?
No. You can still use Firestore native SDKs. Many teams use native SDKs for full functionality and use MongoDB compatibility where it helps reduce migration effort.

4) How does pricing work?
You are billed according to Firestore pricing (reads/writes/deletes/storage/egress). MongoDB-compatible operations ultimately drive these meters.

5) Is Firestore with MongoDB compatibility available in all regions?
Availability can vary. Verify supported regions and release stage in official documentation.

6) Can I use mongosh and MongoDB Compass?
Possibly, but tool support depends on the compatibility layer. Verify supported tools/versions in official docs.

7) How do I authenticate from Cloud Run or GKE?
Prefer IAM-based identity (service account / workload identity). If the compatibility layer requires connection strings/secrets, store them in Secret Manager and rotate.

8) What about backups and point-in-time recovery?
Firestore supports export/import patterns and operational tooling, but details vary. Verify current backup/restore options in official docs and test restores.

9) How do indexes work under MongoDB compatibility?
Firestore indexing rules still apply at the storage layer. Query feasibility and performance will depend on Firestore indexes. Validate how the compatibility layer handles index requirements.

10) Is Firestore strongly consistent?
Firestore consistency characteristics depend on operation type and configuration. Verify the latest consistency model in official docs for your database mode and location.

11) Can I do multi-document transactions like MongoDB?
Firestore supports transactions with specific constraints. MongoDB compatibility may not map 1:1. Verify transaction support and limits.

12) How do I model relationships without joins?
Use document embedding where appropriate, or reference documents and perform application-side joins. Consider denormalization for read-heavy patterns.

13) What are common migration risks?
Data type mapping differences, query semantic differences, unsupported MongoDB features, and different operational limits/quotas.

14) How do I prevent unexpected cost spikes?
Add budgets/alerts, instrument read/write counts, avoid unbounded queries, implement caching, and use rate limiting.

15) Can I use VPC Service Controls with Firestore?
Firestore can integrate with VPC Service Controls in many cases, but configurations and limitations apply. Verify current support and setup guidance in official docs.

16) What’s the safest way to test compatibility?
Run a pilot with representative queries, validate correctness/performance, and compare results with your existing MongoDB workload before migrating.

17. Top Online Resources to Learn Firestore with MongoDB compatibility

Resource Type Name Why It Is Useful
Official product page Cloud Firestore High-level overview, positioning, and entry point to docs: https://cloud.google.com/firestore
Official documentation Firestore documentation Core concepts, SDKs, data model, operations: https://cloud.google.com/firestore/docs
Official pricing Firestore pricing Authoritative pricing model and meters: https://cloud.google.com/firestore/pricing
Official calculator Google Cloud Pricing Calculator Build estimates using region and usage assumptions: https://cloud.google.com/products/calculator
Official security IAM for Firestore Roles, permissions, least-privilege design: https://cloud.google.com/firestore/docs/security/iam
Official quotas/limits Firestore quotas and limits Prevent design/scale surprises: https://cloud.google.com/firestore/quotas
Official observability Cloud Monitoring docs Build dashboards and alerts for database-backed services: https://cloud.google.com/monitoring/docs
Official logging/audit Cloud Audit Logs Governance and compliance logging patterns: https://cloud.google.com/logging/docs/audit
Official architecture Google Cloud Architecture Center Patterns and reference architectures (search for Firestore-related guidance): https://cloud.google.com/architecture
Official samples (general) GoogleCloudPlatform GitHub Many official samples live here; search for Firestore repos: https://github.com/GoogleCloudPlatform
Video learning Google Cloud Tech (YouTube) Talks, tutorials, and product updates: https://www.youtube.com/@googlecloudtech
Community (reputable) Serverless and Firestore best practices (Google Cloud blogs) Practical patterns and tradeoffs; validate against docs: https://cloud.google.com/blog

For MongoDB compatibility-specific documentation, use the Firestore docs navigation/search and release notes. If you can’t find it easily, treat the feature as region/stage-dependent and verify in official docs before implementation.

18. Training and Certification Providers

  1. DevOpsSchool.com – Suitable audience: DevOps engineers, SREs, cloud engineers, developers – Likely learning focus: Google Cloud fundamentals, DevOps, cloud operations, hands-on labs – Mode: Check website – Website URL: https://www.devopsschool.com/

  2. ScmGalaxy.com – Suitable audience: Beginners to intermediate engineers in DevOps/SCM – Likely learning focus: DevOps tooling, CI/CD, SCM practices, foundational cloud workflows – Mode: Check website – Website URL: https://www.scmgalaxy.com/

  3. CLoudOpsNow.in – Suitable audience: Cloud operations, platform engineering, SRE/ops practitioners – Likely learning focus: Cloud operations practices, reliability, automation, monitoring – Mode: Check website – Website URL: https://www.cloudopsnow.in/

  4. SreSchool.com – Suitable audience: SREs, operations teams, platform teams – Likely learning focus: SRE principles, production readiness, observability, incident response – Mode: Check website – Website URL: https://www.sreschool.com/

  5. AiOpsSchool.com – Suitable audience: Ops/SRE and engineering teams exploring AIOps – Likely learning focus: AIOps concepts, monitoring analytics, automation for ops – Mode: Check website – Website URL: https://www.aiopsschool.com/

19. Top Trainers

  1. RajeshKumar.xyz – Likely specialization: DevOps/cloud training content (verify current offerings on site) – Suitable audience: Beginners to professionals seeking practical guidance – Website URL: https://www.rajeshkumar.xyz/

  2. devopstrainer.in – Likely specialization: DevOps training, CI/CD, cloud operations (verify course catalog) – Suitable audience: DevOps engineers, SREs, build/release engineers – Website URL: https://www.devopstrainer.in/

  3. devopsfreelancer.com – Likely specialization: DevOps consulting/training resources (verify services on site) – Suitable audience: Teams needing short-term coaching or implementation support – Website URL: https://www.devopsfreelancer.com/

  4. devopssupport.in – Likely specialization: DevOps support and training resources (verify scope on site) – Suitable audience: Operations teams and engineers needing hands-on support – Website URL: https://www.devopssupport.in/

20. Top Consulting Companies

  1. cotocus.com – Likely service area: Cloud/DevOps consulting (verify exact offerings on website) – Where they may help: Architecture reviews, migration planning, CI/CD and operations setup – Consulting use case examples:

    • Designing a Firestore-based backend architecture on Google Cloud
    • Implementing IAM, logging, monitoring, and cost controls
    • Website URL: https://cotocus.com/

  2. DevOpsSchool.com – Likely service area: DevOps/cloud consulting and training services (verify portfolio) – Where they may help: Delivery enablement, platform engineering practices, workshops – Consulting use case examples:

    • Building a reference architecture for microservices using Firestore
    • Setting up SRE practices and operational dashboards
    • Website URL: https://www.devopsschool.com/

  3. DEVOPSCONSULTING.IN – Likely service area: DevOps and cloud consulting (verify exact services) – Where they may help: Cloud migration, automation, reliability engineering – Consulting use case examples:

    • Migration assessment for MongoDB workloads to Google Cloud databases
    • Security posture review for IAM and secrets management
    • Website URL: https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before this service

  • Google Cloud fundamentals:
  • Projects, billing, IAM, service accounts
  • Networking basics (VPC, Private Google Access concepts)
  • NoSQL fundamentals:
  • Document modeling, denormalization, indexing tradeoffs
  • Basic app deployment:
  • Cloud Run or GKE basics
  • Security basics:
  • Principle of least privilege, secret management, audit logging

What to learn after this service

  • Production operations:
  • Cloud Monitoring dashboards/alerts
  • Error budgets, SLOs, incident response
  • Data pipelines:
  • Pub/Sub, Dataflow, BigQuery for analytics
  • Advanced security:
  • VPC Service Controls, org policies, CMEK (where applicable)
  • Migration engineering:
  • Dual-write patterns, backfills, verification strategies

Job roles that use it

  • Cloud engineer / platform engineer
  • Backend engineer
  • DevOps engineer / SRE
  • Solutions architect
  • Security engineer (for IAM, audit, and governance)

Certification path (if available)

  • Google Cloud certifications that align well:
  • Associate Cloud Engineer
  • Professional Cloud Architect
  • Professional Cloud DevOps Engineer
  • There isn’t typically a certification for one database feature; focus on broader Google Cloud certs and database design skills.

Project ideas for practice

  • Build a multi-tenant profile service on Cloud Run + Firestore with IAM-based service-to-service auth.
  • Implement a rate-limited ingestion endpoint that writes device state documents and exposes dashboards.
  • Prototype a migration: read from existing MongoDB, write to Firestore, validate queries, and cut over gradually (only after validating compatibility constraints).

22. Glossary

  • Cloud Firestore: Google Cloud managed NoSQL document database for application data.
  • Document: A JSON-like record containing fields (strings, numbers, arrays, maps, timestamps).
  • Collection: A group of documents in Firestore.
  • Index: Data structure that accelerates queries; Firestore relies on indexes for many query patterns.
  • Composite index: Index spanning multiple fields to support multi-field filtering/sorting queries.
  • IAM (Identity and Access Management): Google Cloud system for permissions and access control.
  • Service account: Non-human identity used by applications/services.
  • Workload Identity: A mechanism to let workloads authenticate without long-lived keys (recommended for production).
  • Cloud Audit Logs: Logs of administrative actions and (optionally) data access for Google Cloud services.
  • VPC Service Controls: Security feature to create service perimeters to reduce data exfiltration risk.
  • MongoDB driver: Client library that applications use to connect to and query MongoDB-like interfaces.
  • Compatibility layer: An interface that mimics another system’s API to reduce migration effort, often with limitations.

23. Summary

Firestore with MongoDB compatibility (Google Cloud, Databases) is a way to use Cloud Firestore as your managed document database while optionally accessing it through MongoDB-compatible drivers and tools for a supported subset of operations. It matters because it can reduce migration friction for teams coming from MongoDB while still delivering Firestore’s managed scaling and Google Cloud-native security/operations.

Architecturally, it fits best for document-centric workloads with well-defined query patterns and strong needs for managed operations. Cost is driven primarily by Firestore’s usage meters—reads, writes, deletes, storage, and egress—so model your data carefully, instrument operation counts, and add budgets/alerts. Security is strongest when you use IAM least privilege, workload identity (no keys), Secret Manager for sensitive config, and audit logging aligned to compliance needs.

Use it when the supported MongoDB-compatible operations match your application needs and you want to standardize on Firestore. If you require full MongoDB feature parity, consider MongoDB Atlas or self-managed MongoDB instead.

Next step: review the official Firestore docs and quotas, then run a pilot workload that validates query behavior, performance, and cost before any production migration: – https://cloud.google.com/firestore/docs – https://cloud.google.com/firestore/quotas – https://cloud.google.com/firestore/pricing