- Coverage by target cloud
- How the backends compare
- On Google Cloud, Azure, OCI, and Private Kubernetes
- On Google Cloud
- On Azure
- On OCI
- Debug this service
Coverage by target cloud
How the backends compare
Each row compares a capability of DocumentDB (MongoDB) with its adaptation on each backend. A dash means this row is not stated for that backend.Max adaptation
Runtime surface
Limits
Infrastructure-only adaptation
Runtime surface
Limits
On Google Cloud, Azure, OCI, and Private Kubernetes
Via Percona MongoDB
Document queries on Kubernetes
Percona Server for MongoDB runs the database on the target Kubernetes cluster. The Percona Operator reconciles its database resources; applications send MongoDB requests directly to the database. Configure the driver connection, credentials, TLS and reachable replica-set addresses for that deployment. The DocumentDB cluster-management API and the native database connection are separate interfaces. Use the operator’s Kubernetes resources for database administration. Percona Server for MongoDB and Operator 1.22 documentation.MongoDB compatibility and version differences
The target baseline is Operator 1.22 with MongoDB 8.0. Source behavior depends on the DocumentDB engine version: graphLookup is supported in 8.0, while correlated lookup is supported from 8.0.2 with restrictions on stages referencing let variables. Earlier versions lack the corresponding capability. Percona executes native MongoDB correlated lookup and graph traversal. Capped collections retain a bounded set of documents; time-series collections organize measurements. These native collection designs require deliberate schema choices rather than an automatic conversion. Both engines support text indexes, with different indexing and language behavior. DocumentDB 8.0 adds collation and mapReduce; MongoDB 8.0 also supports collation and server-side JavaScript, but JavaScript and mapReduce are deprecated. Review locale-sensitive queries and keep unnecessary server-side scripting disabled. DocumentDB promotes transaction read concern to snapshot and write concern to majority. MongoDB replica-set transactions use the configured concerns; choose them and test retry handling. DocumentDB change streams must be enabled and retain a configured history window. MongoDB streams follow its replica-set oplog, so oplog capacity determines how far a consumer can resume. DocumentDB differences and API support, transactions, change streams, and the MongoDB manual.Limitations
Vector search differs. The MongoDB 8.0 baseline has no native vector-search engine. Percona Search adds vector and full-text search on newer engines through a separate mongot process. Its availability does not make DocumentDB vector queries or index definitions interchangeable. Database management uses a different interface. DocumentDB cluster-management requests, AWS snapshot identifiers and parameter groups are not Percona Operator resources. Use native operator administration and backup tools for this mapping; application wire compatibility does not establish AWS management-API compatibility. Percona Search.Other considerations
Operations and recovery. Assign an operating owner for database capacity, persistent storage, failure placement, monitoring, upgrades and recovery under the installation agreement. The Kubernetes operator automates database tasks; it does not assign those responsibilities or supply AWS-managed storage durability or an AWS service availability commitment. Configure Percona Backup for MongoDB and backup storage separately. Point-in-time recovery requires a full backup and retained oplog; rehearse a restore and verify the recovered application. Assign support ticket ownership, incident coordination and escalation separately from the backend operating owner; the installation agreement determines those responsibilities. Data migration. Provision the target before loading data. Rehearse a logical dump and restore, stop application writes for the final transfer, then compare document counts, indexes and representative query results. Switch the connection only after validating the target. Recreate users and connection security for the new deployment, and retain a rollback plan that accounts for writes after cutover. Operator 1.22 recovery guidance and DocumentDB export tools.Via MongoDB Atlas
How it works
Your application’s MongoDB driver connects directly to MongoDB Atlas. These database requests are the data plane. The driver and the MongoDB wire protocol stay the same, and Tensor9 does not proxy or translate them. Management requests, such as snapshots, restores, replicas, failover and configuration changes, are the control plane. Tensor9 runs the DocumentDB API in the customer’s appliance and translates each of these requests to the backend’s management API. The sections below list which operations work and which return an error.
Queries reach the database directly; only the management calls are translated.
Database connections
MongoDB Atlas runs MongoDB itself. It supports multi-document transactions, change streams, correlated lookups and collation, with behavior and limits that follow the selected MongoDB version and Atlas tier. Your driver connects directly to Atlas, where your queries and indexes run. Each backend implements a different set of MongoDB features. The comparison table on this page covers transactions, change streams, lookups, text and vector search, and other features your application may use.Database management
At runtime your application and tools keep making the same DocumentDB calls: describe the cluster, take a snapshot, restore to a point in time, add replica instances, pause and resume, change the tier or a parameter. For each supported operation, the adapter accepts the DocumentDB request, returns the DocumentDB response format, and performs the operation through the Atlas Admin API: snapshots and continuous-backup point-in-time restore, replica node layout, cluster pause / resume, and tier and storage changes. DocumentDB’s global-cluster calls map to replica placement across Atlas regions. Atlas also offers geographic sharding, which splits data by location and is a separate deployment choice. When your product is deployed into the customer environment, Tensor9 compiles the cluster your stack already declares into the matching MongoDB Atlas resources and puts the connection string and credentials in your application’s configuration. The adapter then handles the management calls your running system makes.
Tensor9 translates DocumentDB management requests to the backend API and returns DocumentDB responses.
Limitations
Where DocumentDB and MongoDB Atlas differ- Manual failover behaves differently: it runs an Atlas failover test. Atlas elects a new primary automatically. The manual failover call maps to Atlas’s test-failover, which is meant for checking resilience rather than day-to-day operations.
- Event subscriptions are not supported. DocumentDB event notifications publish to SNS. Atlas alerts work differently and have no direct equivalent.
- DocumentDB-specific parameters are not supported. Standard cluster parameters map to Atlas cluster configuration; parameters specific to DocumentDB have no equivalent on the backend.
Other considerations
Migration. Copy existing data with MongoDB migration tools that the backend supports. Check the workload’s queries, indexes and BSON types against the comparison table before switching connections; sharing a wire protocol does not make every MongoDB feature equivalent. Operations. The customer owns the Atlas organization. Cluster tiers, cloud and region choices, and pricing are MongoDB’s. Features and capacity. The comparison table on this page lists feature and high-availability differences. Check the backend’s pricing and capacity limits when you size the deployment.On Google Cloud
Via Firestore (MongoDB compatibility)
How it works
Your application’s MongoDB driver connects directly to Firestore with MongoDB compatibility. These database requests are the data plane. The driver and the MongoDB wire protocol stay the same, and Tensor9 does not proxy or translate them. Management requests, such as snapshots, restores, replicas, failover and configuration changes, are the control plane. Tensor9 runs the DocumentDB API in the customer’s appliance and translates each of these requests to the backend’s management API. The sections below list which operations work and which return an error.
Queries reach the database directly; only the management calls are translated.
Database connections
Firestore with MongoDB compatibility supports the MongoDB 7.0 wire protocol. Firestore manages instance sizing, read scaling and multi-region high availability for you. Its MongoDB compatibility has limits: no vector search or collation, many unsupported aggregation stages, and change streams in preview. Your driver connects directly to Firestore. Each backend implements a different set of MongoDB features. The comparison table on this page covers transactions, change streams, lookups, text and vector search, and other features your application may use.Database management
At runtime your application and tools keep making the same DocumentDB calls. For each supported operation, the adapter accepts the DocumentDB request, returns the DocumentDB response format, and performs the operation through the Firestore API: on-demand backups, point-in-time recovery within Firestore’s 7-day window, and database-level settings. Much of the rest has nothing to map to, because Firestore is serverless: reads scale automatically, failover is automatic, and there is no cluster to stop, start or size. The limitations below list those operations; each returns an error. When your product is deployed into the customer environment, Tensor9 compiles the cluster your stack already declares into the matching Firestore with MongoDB compatibility resources and puts the connection string and credentials in your application’s configuration. The adapter then handles the management calls your running system makes.
Tensor9 translates DocumentDB management requests to the backend API and returns DocumentDB responses.
Limitations
Where DocumentDB and Firestore (Mongo compat) differ- Instance controls are not supported. Firestore is serverless: there are no replica instances to add, no manual failover, no stop / start, and no compute or storage sizing. Reads scale and fail over automatically.
- Multi-region behaves differently: you choose it when the database is created. The database’s location is fixed at creation. There is no global-cluster object and no switchover call.
- Most cluster parameters are not supported. Database-level settings (point-in-time recovery, delete protection) map; most DocumentDB cluster parameters have no equivalent.
- Event subscriptions are not supported. DocumentDB event notifications publish to SNS. Cloud Monitoring works differently and has no direct equivalent.
Other considerations
Migration. Copy existing data with MongoDB migration tools that the backend supports. Check the workload’s queries, indexes and BSON types against the comparison table before switching connections; sharing a wire protocol does not make every MongoDB feature equivalent. Operations. The customer owns the Firestore database in their Google Cloud project. Quotas and pricing are Google’s. Features and capacity. The comparison table on this page lists feature and high-availability differences. Check the backend’s pricing and capacity limits when you size the deployment.On Azure
Via Azure Cosmos DB for MongoDB (vCore)
How it works
Your application’s MongoDB driver connects directly to Azure Cosmos DB for MongoDB (vCore). These database requests are the data plane. The driver and the MongoDB wire protocol stay the same, and Tensor9 does not proxy or translate them. Management requests, such as snapshots, restores, replicas, failover and configuration changes, are the control plane. Tensor9 runs the DocumentDB API in the customer’s appliance and translates each of these requests to the backend’s management API. The sections below list which operations work and which return an error.
Queries reach the database directly; only the management calls are translated.
Database connections
DocumentDB and Cosmos vCore each implement part of the MongoDB API. Both support graph lookups when the DocumentDB source uses engine version 8.0. DocumentDB 8.0.2 adds restricted correlated lookups, which this target does not provide. Cosmos vCore does not support server-side mapReduce, and it limits multi-document transactions to 30 seconds. Your driver connects directly to Cosmos vCore, where your queries and indexes run. Each backend implements a different set of MongoDB features. The comparison table on this page covers transactions, change streams, lookups, text and vector search, and other features your application may use.Database management
At runtime your application and tools keep making the same DocumentDB calls: describe the cluster, take a snapshot, restore to a point in time, add replicas, trigger a failover, change the tier or a parameter. For each supported operation, the adapter accepts the DocumentDB request, returns the DocumentDB response format, and performs the operation on Azure: snapshots and point-in-time restore to a new cluster, replica clusters, manual failover (forced or graceful promotion), and tier and storage updates. Global-cluster calls map to Cosmos vCore’s single secondary region. When your product is deployed into the customer environment, Tensor9 compiles the cluster your stack already declares into the matching Azure Cosmos DB for MongoDB (vCore) resources and puts the connection string and credentials in your application’s configuration. The adapter then handles the management calls your running system makes.
Tensor9 translates DocumentDB management requests to the backend API and returns DocumentDB responses.
Limitations
Where DocumentDB and Cosmos DB (vCore) differ- Stop and start are not supported. Cosmos vCore has no pause; a cluster runs continuously.
- Only one secondary region is supported. There is no multi-region global-cluster object. Cross-region maps to a single secondary region with forced or graceful failover.
- Event subscriptions are not supported. DocumentDB event notifications publish to SNS. Azure Monitor works differently and has no direct equivalent.
- DocumentDB-specific parameters are not supported. Standard cluster parameters map to the cluster’s configuration; parameters specific to DocumentDB have no equivalent on the backend.
Other considerations
Migration. Copy existing data with MongoDB migration tools that the backend supports. Check the workload’s queries, indexes and BSON types against the comparison table before switching connections; sharing a wire protocol does not make every MongoDB feature equivalent. Operations. The customer owns the Cosmos DB cluster in their Azure subscription. Maintenance windows, quotas and pricing are Microsoft’s. Features and capacity. The comparison table on this page lists feature and high-availability differences. Check the backend’s pricing and capacity limits when you size the deployment.On OCI
Via Oracle Autonomous JSON Database (MongoDB API)
How it works
Your application’s MongoDB driver connects directly to Oracle Autonomous JSON Database. These database requests are the data plane. The driver and the MongoDB wire protocol stay the same, and Tensor9 does not proxy or translate them. Management requests, such as snapshots, restores, replicas, failover and configuration changes, are the control plane. Tensor9 runs the DocumentDB API in the customer’s appliance and translates each of these requests to the backend’s management API. The sections below list which operations work and which return an error.
Queries reach the database directly; only the management calls are translated.
Database connections
Autonomous JSON Database accepts your driver’s connections through the Oracle Database API for MongoDB, which supports a MongoDB-4.2-era protocol and runs operations on Oracle’s SQL / JSON engine. Your driver connects directly using a load-balanced connection string. You can also query those collections with SQL, which DocumentDB does not offer. Some newer MongoDB features are missing; see the comparison table on this page. Each backend implements a different set of MongoDB features. The comparison table on this page covers transactions, change streams, lookups, text and vector search, and other features your application may use.Database management
At runtime your application and tools keep making the same DocumentDB calls. For each supported operation, the adapter accepts the DocumentDB request, returns the DocumentDB response format, and performs the operation on OCI: backups and point-in-time recovery within the retention window, stop / start, and online compute and storage scaling. Operations that OCI has no equivalent for are listed under Limitations; each returns an error. When your product is deployed into the customer environment, Tensor9 compiles the cluster your stack already declares into the matching Oracle Autonomous JSON Database resources and puts the connection string and credentials in your application’s configuration. The adapter then handles the management calls your running system makes.
Tensor9 translates DocumentDB management requests to the backend API and returns DocumentDB responses.
Limitations
Where DocumentDB and Autonomous JSON Database differ- Manual failover and cross-region standbys are not supported. Autonomous Data Guard is not available for JSON workloads, so there is no failover or switchover call and no global database. For cross-region disaster recovery, use backup copies, refreshable clones or replication tooling.
- Replica instances are not supported. Read scale-out comes from compute auto-scaling (up to 3x), not replicas you add.
- Most cluster parameters are not supported. Compute and storage scale online; most DocumentDB cluster parameters have no equivalent.
- Event subscriptions are not supported. DocumentDB event notifications publish to SNS. OCI Events works differently and has no direct equivalent.