Why MongoDB Struggles vs Redis in China: The Positioning Dilemma

Core Thesis: MongoDB's Awkward Positioning

The article compiles high-voted Zhihu answers explaining why MongoDB has not achieved the same level of adoption as Redis in the Chinese market. The central argument is that MongoDB's positioning is "awkward" — it falls between caching and database roles without excelling in either.

Caching Domain: Redis Dominates

In caching, Redis remains the "absolute king." For small-scale needs (under 1,000 nodes), Redis Cluster suffices. For larger scale, multi-level sharding middleware like Camellia is used; one cited project runs 2,300 Redis nodes (64 GB each). Emerging alternatives further squeeze MongoDB: distributed KV stores (TiKV, Apache Kvrocks, Apache Pegasus) with automatic hot/cold separation and unlimited storage, and in-memory grids (Hazelcast, Apache Ignite) that act as true distributed cache replacements.

Database Domain: Document Model vs. SQL Ecosystem

MongoDB pursues a document-database path, but its JSON/BSON advantage has eroded as MySQL, PostgreSQL, and Redis (via ReJSON) all now support JSON operations natively. For OLTP, MongoDB cannot compete with MySQL-compatible distributed databases like TiDB, OceanBase, PolarDB, TDSQL, GoldenDB, or GaussDB because it lacks full SQL compatibility ("SQL is fragmentary") and strong transaction guarantees — schema-free design is a liability in financial/transactional cores. For OLAP, it is outmatched by modern lakehouse engines (ClickHouse, Hudi, Iceberg, Paimon, Doris, StarRocks) and the Hadoop/Spark/Flink stack.

Operational Complexity and DBA Scarcity

MongoDB operations are significantly more complex than MySQL: replica-set configuration and election mechanics, sharded cluster components (Config Server, Mongos), distinct index design, and far fewer troubleshooting resources online. The Chinese DBA workforce is overwhelmingly MySQL-centric; companies typically assign MySQL DBAs to manage MongoDB part-time, leading to mismanagement because relational and document data models require fundamentally different thinking. Skilled MongoDB DBAs are described as a "scarce species."

Sharding Key: A Critical Immutable Decision

The shard key is called "MongoDB operations' biggest pit." Once chosen, it cannot be changed (official documentation states it is immutable for life). A poorly chosen key causes severe hotspot skew — all data routes to one shard while others idle. Fixing it requires building a new cluster, redesigning the shard key, and migrating terabytes of data.

Risk Profile: Cache Failure vs. Core Data Loss

Redis is mostly used as a cache; failure causes cache avalanche but the primary data remains in MySQL. Recovery is a restart and warm-up — a manageable incident. MongoDB often stores core business data (orders, user profiles, IoT telemetry). Its failure or data loss is a P0 incident with severe consequences (performance penalties, dismissal). This risk asymmetry makes organizations hesitant to adopt MongoDB for critical workloads.

Schema-less Freedom Leading to Technical Debt

Developers enjoy MongoDB's schema-less flexibility — adding fields, changing types without constraints. Over time, collections become unmaintainable: unknown structures, mixed formats, and unoptimizable queries. By the time governance is attempted, it is too late. Additionally, MongoDB's space-for-time trade-off clashes with Chinese enterprises' cost sensitivity (storage costs money, latency is tolerated).

Weak JOIN Support Limits Complex Business Logic

MongoDB's limited JOIN support restricts it to simple, log-like scenarios; it cannot handle complex business relationships that require multi-table joins.

Historical Context

Early MongoDB versions (0.x) had almost no persistence and targeted Redis, Memcached, Tokyo/Tyrant Cache. It gradually added GridFS, transactions, and multi-replica distribution to become a high-capacity distributed database, but this evolution left it stranded between categories.