Single service comparison

Cosmos DB is one engine serving five APIs (SQL, MongoDB, Cassandra, Gremlin, Table) under a single account, billed on provisioned RU/s and storage. Huawei splits this across two products: GeminiDB covers key-value/wide-column/time-series via Redis, DynamoDB, Cassandra, HBase and InfluxDB protocol APIs on decoupled storage/compute, while Document Database Service (DDS) separately covers MongoDB-compatible document workloads. There is no single Huawei account that spans all Cosmos DB API surfaces, so workload partitioning must be explicit and Cosmos DB SQL/Core and Gremlin graph APIs have no direct Huawei equivalent.

Cosmos DB partitions every container by a logical partition key under physical partitions sized to RU/s, and writes are replicated within one logical partition per session. DDS uses MongoDB sharding (config server plus mongos plus shard replica sets) with up to 32 shards, retaining MongoDB's sharding semantics; DDS three-copy replica sets give HA failover. GeminiDB uses a shared-storage, compute-stateless architecture where storage is a distributed three-copy pool and compute nodes scale in minutes independent of storage, which differs from Cosmos DB's partition-attached storage model and changes how scaling, hot-spot handling, and capacity planning must be reasoned about.

Operationally, Cosmos DB ships multi-region write with configurable consistency and conflict resolution as first-class control-plane features, plus change feed and serverless provisioned tiers. GeminiDB and DDS are regional managed services; cross-region disaster recovery and global distribution require Huawei disaster recovery or object-storage-level replication rather than the built-in multi-region catalog. Backup differs too: DDS supports up to 732-day automated retention with point-in-time recovery, while Cosmos DB tier backup/continuous backup have their own SLAs. Expect to re-model global topology, change feed consumers, and consistency-driven code rather than assume parity.

Start by classifying each Cosmos DB API surface. Map SQL/Core and Gremlin (graph) containers to a re-design exercise with no native target; map MongoDB-API collections to DDS (validate engine versions and aggregation support against the documented compatibility matrix); map Cassandra-API tables and DynamoDB-compatible/Table workloads to GeminiDB Cassandra API or GeminiDB DynamoDB-Compatible API; map time-series if present to GeminiDB Influx API. Do not assume one-to-one parity: assess indexes, partition keys, TTL, unique constraints, and stored procedure equivalents per container before selecting DDS, GeminiDB, or an alternative.

For data movement, use Huawei DRS for MongoDB-to-DDS migration with documented minimal-downtime migration, and follow the official GeminiDB DynamoDB-Compatible API migration guidance for DynamoDB-API/Table workloads; there is no documented one-click Cosmos DB to Huawei path. Bulk/initial loads typically use export to OBS or DRS full-phase, then incremental/CDC synchronization before cutover. Re-implement change feed consumers against DDS change streams or GeminiDB CDC equivalents, and rework Cosmos DB triggers and user-defined functions as application-side logic since server-side JS execution has no direct equivalent.

Re-architect global topology and consistency behavior. Cosmos DB multi-region write and session/bounded-staleness consistency need to be replaced with application-level quorum logic, Huawei cross-region disaster recovery, or a chosen single-writer region. Re-tune request volume to Huawei sizing: DDS charges per node spec and storage plus backup, GeminiDB charges per node and storage with tiered hot/cold storage, and DRS task billing applies. Recalculate TCO with peak load, request volume, retention period, and cross-region/interconnect traffic before production cutover, because RU-based throughput provisioning does not map linearly to node-based billing.

Validation must be feature-by-feature for control plane, data plane, and operational behavior: confirm supported API versions, indexing, aggregation operators, and consistency levels in DDS/GeminiDB release notes for your target region, and account for regional availability differences. Address gaps explicitly where parity does not exist (graph API, Cosmos DB SQL query dialect, serverless autoscale tiers, built-in conflict resolution). Run a parallel-run or read-replica comparison phase and cut over only after latency, throughput, and consistency tests meet the original service's observed baselines; assume gaps rather than parity until proven.