DynamoDB vs Cassandra: Managed Service or Operational Control
DynamoDB and Cassandra share ideas from Amazon’s Dynamo paper, but the production decision is about responsibility: AWS controls DynamoDB’s machinery, while a Cassandra operator controls—and must continuously verify—the whole database.
Situation
Both systems favor query-driven schemas, high-cardinality partition keys, and denormalized access paths. Both can replicate across geographic boundaries and support conditional operations. Those similarities encourage a misleading shorthand: DynamoDB is “managed Cassandra,” or Cassandra is “portable DynamoDB.”
They are not interchangeable. DynamoDB exposes tables, indexes, streams, capacity modes, consistency options, and service quotas. Cassandra exposes the token ring, replicas, consistency levels, compaction, repair, hardware, and software lifecycle. An application that fits one key model can still fail the other product’s consistency or operating constraints.
The Problem
Suppose an identity service stores 2 KB session records, reads by account and expiry time, performs conditional session revocation, and runs in three regions. The sustained rate, burst ratio, hottest-account distribution, permitted staleness, and exact regional write policy are still required before capacity or cost can be estimated.
The core question is: does the workload benefit more from DynamoDB’s bounded managed interface, or from Cassandra’s control over topology and per-operation replica coordination?
Partitioning and Coordination
flowchart TD
A["Request with partition key"] --> B{"Platform"}
B -->|DynamoDB| C["AWS-managed physical partition"]
B -->|Cassandra| D["Coordinator maps token to replicas"]
C --> E["Table and index capacity controls"]
D --> F["Consistency level selects acknowledgements"]
E --> G["Service metrics and quota response"]
F --> H["Repair, compaction, and node response"]
G --> I["Validate application correctness"]
H --> I
DynamoDB: A Managed Boundary with Physical Limits
DynamoDB hashes the partition-key value to place items. A composite primary key groups items by partition key and orders them by sort key. AWS recommends uniform activity across table and index keys and documents 1,000 write units and 3,000 read units per second as the design maximum for a physical partition. Item size determines unit consumption.
Adaptive capacity can allocate more of a table’s capacity to uneven partitions, but it does not make one hot item unbounded. On-demand mode removes provisioned-capacity planning, not key-distribution or account-quota planning. A burst beyond the table’s recent peak or quota still requires pre-warming, quota preparation, or application backpressure according to the documented scaling behavior.
Global secondary indexes are independent access paths. They propagate asynchronously, consume their own capacity and storage, and cannot serve strongly consistent reads. In provisioned mode, an under-capacity GSI can throttle base-table writes. Each GSI therefore belongs in the write-amplification and incident model.
Cassandra: Control Is Coupled to Correctness Work
Cassandra hashes the partition key into a token range. Any node can coordinate a request, identify replicas from the keyspace replication strategy, and wait for the selected consistency level. With NetworkTopologyStrategy, replication factors are declared per datacenter.
This permits explicit tradeoffs. LOCAL_QUORUM keeps the acknowledgement requirement within the coordinator’s local datacenter—a majority of that datacenter’s replicas—so the response does not wait for a remote-datacenter quorum. Cassandra still sends writes to all replicas. Lower consistency can favor availability; lightweight transactions provide linearizable compare-and-set semantics using Paxos. The tradeoff must be calculated from replication factor and failure tolerance, not inferred from the word “quorum.”
Cassandra uses mutation timestamps and last-write-wins reconciliation, so clock health is part of correctness. Hints and read repair help replicas converge, but anti-entropy repair is the documented convergence mechanism. Compaction rewrites SSTables and reclaims obsolete data. Operators own the capacity, cadence, and failure handling for both.
Multi-Region Is Not One Feature
DynamoDB global tables have multiple consistency modes. Multi-Region eventual consistency uses asynchronous replication and last-writer-wins conflict resolution. Multi-Region strong consistency, introduced in 2025, has topology and feature constraints: current AWS documentation requires exactly three replica Regions or two replica Regions plus a witness Region. Existing design assumptions must be checked against the current mode rather than treating every global table as strongly consistent.
Cassandra commonly stretches one logical cluster across datacenters and lets clients select local or cross-datacenter consistency levels. This offers topology control, but wide-area quorum latency and partition availability follow directly from the chosen level. Independent regional clusters plus application replication are another architecture, with a different conflict and recovery model.
In either system, write down:
- Which regions accept writes.
- What a read may return immediately after a remote write.
- How conflicts are prevented or resolved.
- Which failures sacrifice availability versus consistency.
- How a region is reintroduced without serving stale state.
In Practice
The evidence-backed pattern is not a fabricated request-rate crossover. AWS documents partition-level capacity, GSI backpressure, on-demand scaling, and global-table consistency constraints. Cassandra documents token-based placement, tunable consistency, timestamp reconciliation, and mandatory anti-entropy repair.
For the assumed session workload, run two correctness experiments before a throughput benchmark. First, race conditional revocations from separate regions and verify the resulting invariant. Second, isolate one region, continue permitted operations, reconnect it, and observe conflict resolution and convergence. Only after the semantics pass should the team measure latency and cost under the real hottest-account distribution.
DynamoDB is generally favored when AWS is the intended platform, key-based access fits, and the organization wants AWS to own the database fleet. Cassandra is favored when infrastructure placement, provider independence, custom topology, or per-operation replica control is a hard requirement and a database operations team is funded. There is no defensible universal request-rate at which the answer flips.
Cost and Staffing Model
Do not compare DynamoDB request charges with Cassandra virtual machines alone. Use a scenario model that includes:
- DynamoDB item sizes, table and GSI reads/writes, streams, storage, backups, cross-region replication, transfer, and headroom.
- Cassandra nodes per failure domain, replication, disk reserve, repair and compaction headroom, backup storage, network, observability, upgrade environments, and on-call labor.
- The same retention, availability target, regional topology, and recovery objective for both.
Publish the region, price date, workload trace, utilization target, and uncertainty range. Without those inputs, a three-year TCO number is marketing, not engineering evidence.
Where It Breaks
| Choice | Failure mode | Required evidence |
|---|---|---|
| DynamoDB | Hot key reaches a physical partition boundary | Key-frequency histogram and throttling-reason alarms |
| DynamoDB | GSI propagation or capacity violates the read/write contract | Index-specific load and stale-read tests |
| DynamoDB | Global-table mode does not meet regional correctness | Documented mode, topology, and partition drill |
| Cassandra | Repairs do not finish within policy | Repair history, alerts, and capacity reserve |
| Cassandra | Clock skew changes last-write-wins outcomes | Time-sync monitoring and conflict test |
| Cassandra | Operations team is assumed rather than staffed | Named ownership for upgrades, repair, compaction, backup, and restore |
What to Do Next
- Problem: Shared ancestry hides different consistency and ownership boundaries.
- Solution: Model keys, replica coordination, regional writes, indexes, and recurring operations explicitly.
- Proof: Test hot keys, conditional conflicts, region isolation, convergence, and restore with production-shaped data.
- Action: Approve the platform only after the correctness contract and full-cost scenario are versioned in an ADR.