MongoDB vs Cassandra: scritture su scala planetaria

MongoDB and Apache Cassandra both handle distributed data at scale, but with fundamentally different architectures. MongoDB uses a leader-follower (primary-secondary) model where writes go to a single primary per replica set. Cassandra uses a leaderless (peer-to-peer) model where any node can accept any write. This architectural difference drives every performance, consistency, and operational tradeoff between the two.

In Cassandra, all nodes are equal peers in a ring topology. A write can be sent to any node (the coordinator), which forwards it to the N replica nodes responsible for that row's partition key. The number of nodes that must acknowledge the write is configured by the consistency level (e.g., ONE, QUORUM, ALL). This architecture eliminates the single-primary bottleneck and enables truly multi-master, multi-region writes — every data center can accept writes simultaneously.

Cassandra is optimised for extremely high write throughput. Writes are appended to a commit log and a fast in-memory structure (Memtable) before being flushed to disk (SSTables) in bulk. This append-only approach means writes never conflict on disk and throughput scales linearly with node count. IoT platforms ingesting millions of measurements per second, event logging systems, and time-series workloads with write rates that overwhelm a single MongoDB primary are prime Cassandra use cases.

Cassandra's consistency level is tunable per query. ONE means one replica acknowledges (fastest, weakest consistency). QUORUM means a majority of replicas acknowledge (balances latency and consistency). ALL means all replicas acknowledge (slowest, strongest consistency). The key formula: if read consistency + write consistency > replication factor, you get strong consistency. This flexibility allows Cassandra to serve different workloads differently within the same cluster.

Cassandra's data model is fundamentally query-driven. You design tables to answer specific queries efficiently — there is no ad-hoc query engine like MongoDB's. Tables must be partitioned by a partition key (which determines which node stores the row), and rows within a partition are sorted by a clustering key. Secondary indexes exist but are far less capable than MongoDB's. Complex queries (joins, aggregations, multi-field filters) that MongoDB handles with the aggregation pipeline are not possible in standard CQL.

MongoDB's aggregation pipeline and rich query operators allow ad-hoc queries across any field. Need to find all users in Istanbul who purchased a specific product in the last 30 days? A MongoDB query with the right compound index answers this directly. In Cassandra, you would need a pre-designed table for this specific query, or denormalise data into multiple tables, or use Spark for analytical queries. MongoDB is far more flexible for evolving query requirements.

Cassandra's leaderless, multi-datacenter replication allows active-active deployments: all regions accept writes simultaneously. A user in New York writes to the US datacenter; the same user's data replicates asynchronously to Europe and Asia. MongoDB supports multi-region through replica set read preferences and global clusters (Atlas), but writes must still route to a single primary region. For applications requiring zero-latency writes from every region, Cassandra has a structural advantage.

MongoDB with w: majority provides strong consistency — once a write is acknowledged, all subsequent reads return the new value. Cassandra's default configuration is eventual consistency — a write acknowledged with ONE may not immediately be visible on reads from other replicas. Applications must tolerate this or configure QUORUM reads/writes to achieve strong consistency at the cost of higher latency. This affects application complexity significantly.

Both systems require operational expertise, but in different areas. MongoDB's replica set architecture is well-understood, and Atlas automates nearly all ops. Cassandra's ring topology requires careful capacity planning, token management, compaction monitoring, and tombstone management. Deletes in Cassandra produce tombstones that can accumulate and degrade read performance over time. MongoDB's delete model is simpler operationally. For small to mid-size teams, MongoDB's operational overhead is generally lower.

Both databases are used for IoT and time-series workloads, but with different approaches. Cassandra's time-series partitioning (partition by device, cluster by time) delivers extremely high write throughput and efficient time-range scans per device. MongoDB's native time series collections (added in 5.0) close much of the gap with automatic bucketing and columnar storage. For write rates in the millions per second across thousands of devices, Cassandra still has the edge. For workloads under this scale with richer query needs, MongoDB time series is often more practical.

Use Cassandra when: write throughput is in the millions per second; multi-region active-active writes are required; the access pattern is highly predictable (table-per-query); and data retention TTLs are simple. Use MongoDB when: query patterns evolve frequently; complex aggregations and joins are needed; document flexibility is valued; team size is small to medium; or you need full ACID transactions across documents.

In this lesson you learned: Cassandra's leaderless architecture enables massive write throughput and true active-active multi-region writes that MongoDB's primary-secondary model cannot match, Cassandra's query model is schema/table-first while MongoDB supports rich ad-hoc queries, and the decision between them comes down to write scale requirements, query flexibility needs, and team operational capacity. Next up we compare MongoDB with DynamoDB.