Skip to content

Cassandra vs DynamoDB

1. Decision

Choose Apache Cassandra (or ScyllaDB) when you require an open-source, cloud-agnostic, self-hosted distributed Wide-Column store with full control over hardware tuning, JVM garbage collection, and custom compaction strategies; choose AWS DynamoDB when building serverless AWS-native applications requiring zero operational cluster management, predictable single-digit millisecond latency at scale, and pay-per-request pricing.

2. 30-Second Answer

Both Apache Cassandra and AWS DynamoDB share architectural roots in the seminal Amazon Dynamo paper (consistent hashing, partition keys, wide-column data modeling). Cassandra is open-source and masterless, requiring engineering teams to manage node provisioning, repair tasks, compaction, and JVM tuning. AWS DynamoDB is a fully managed, serverless database operated by AWS, featuring automatic partition splitting, Global Tables (multi-region replication), Global Secondary Indexes (GSI), and integrated IAM authentication. Cassandra offers open-source portability and fine-grained tunable consistency (\(R+W>N\)), whereas DynamoDB eliminates operational toil with serverless auto-scaling and predictable SLA performance.

3. Decision Matrix

Option Best For Avoid When Latency Scalability Consistency Operational Complexity
Apache Cassandra Multi-cloud, on-premise, extreme throughput (>500k QPS), deep hardware optimization Small engineering teams, serverless architectures, zero operational budget Ultra-low write (<2ms); Low read Linear scale (Add nodes to ring) Tunable (\(ONE\), \(QUORUM\), \(ALL\)) High (Compaction, Node Repair, JVM tuning)
AWS DynamoDB AWS-native serverless apps, unpredictable traffic spikes, zero ops management Multi-cloud portability, massive continuous write volume where per-request pricing becomes cost-prohibitive Single-digit ms (<5ms) Fully automatic partition splitting and auto-scaling Eventual default; Strong consistent reads (2x cost); ACID Transactions Low (Serverless / Managed)

4. Selection Rules

Requirement Best Choice Rationale / Example
Cloud-Agnostic / On-Prem Deployment Cassandra Pure open-source software runnable on bare metal, GCP, Azure, or AWS
Zero Operational Overhead (Serverless) DynamoDB AWS manages partition provisioning, SSD hardware, and hardware failovers
Global Multi-Region Active-Active DynamoDB DynamoDB Global Tables provides fully managed multi-region replication
Deep Compaction & Storage Engine Control Cassandra Tune SSTable Compaction Strategies (Leveled, Size-Tiered, Time-Window)
AWS IAM Native Security Integration DynamoDB Fine-grained row-level access control via AWS IAM policies
Predictable Serverless On-Demand Pricing DynamoDB Pay strictly per Read/Write Capacity Unit (RCU/WCU) or On-Demand request

5. Tradeoffs

  1. Self-Hosted Control vs Fully Managed Serverless
  2. Gain (Cassandra): Complete ownership of performance, hardware, storage compaction, and cost per node.
  3. Lose (Cassandra): Significant operational toil (node replacement, nodetool repair, anti-entropy sync).
  4. Open-Source Portability vs Cloud Vendor Lock-In
  5. Gain (Cassandra): Deploy across GCP, AWS, Azure, or hybrid private clouds seamlessly.
  6. Lose (Cassandra): Lack of serverless auto-scaling out-of-the-box.
  7. Fine-Grained Quorum Tuning vs Standard Read/Write Consistency Options
  8. Gain (Cassandra): Set arbitrary read/write levels per query (LOCAL_QUORUM, EACH_QUORUM).
  9. Lose (Cassandra): Increased risk of misconfiguration leading to stale data anomalies.
  10. Cost Economics at Scale
  11. Gain (DynamoDB): Cheaper for bursty/intermittent workloads via On-Demand mode.
  12. Lose (DynamoDB): High continuous throughput (>100k WCU) becomes significantly more expensive than Cassandra hardware nodes.
  13. Secondary Indexes Implementation
  14. Gain (DynamoDB): Global Secondary Indexes (GSI) automatically replicate updates asynchronously into separate partitions.
  15. Lose (DynamoDB): GSIs consume additional Write Capacity Units (WCU); throttling GSI throttles main table writes.

6. Interview Counter Questions

  1. How do Partition Keys and Sort Keys work in DynamoDB compared to Cassandra's Partition and Clustering Keys?
  2. What causes DynamoDB Partition Throttling and how do hot keys degrade performance?
  3. How does DynamoDB Global Tables handle concurrent multi-region write conflicts?
  4. What is the difference between DynamoDB Local Secondary Indexes (LSI) and Global Secondary Indexes (GSI)?
  5. How does DynamoDB Transactions (TransactWriteItems) compare to Cassandra Lightweight Transactions (LWT)?
  6. Why can sustained high-velocity write workloads be 5x cheaper on Cassandra/ScyllaDB than DynamoDB?
  7. What is DynamoDB Streams and how is it used for Change Data Capture (CDC)?
  8. How does DynamoDB DAX (DynamoDB Accelerator) differ from standard Redis caching?
  9. What happens when a DynamoDB partition exceeds the 10GB size limit?
  10. How do anti-entropy repairs work in Cassandra (nodetool repair) vs DynamoDB's background storage checks?

7. Gold Standard Answers

  1. Conceptually identical: Partition Key (Hash Key) hashes data across physical storage nodes; Sort Key (Clustering Key) sorts rows physically on disk within that partition page.
  2. Partition throttling occurs when requests exceed 1,000 WCU or 3,000 RCU on a single 10GB partition. Hot keys targeting a single partition key concentrate traffic beyond node limits, triggering ProvisionedThroughputExceededException.
  3. DynamoDB Global Tables uses a "last-writer-wins" conflict resolution mechanism based on system timestamps. If updates to the same attribute occur concurrently in two regions, the update with the latest timestamp prevails.
  4. LSI uses the same partition key as the main table but a different sort key, created at table creation time and sharing the partition's 10GB limit. GSI uses a different partition key and sort key, maintained asynchronously with its own throughput allocation.
  5. DynamoDB TransactWriteItems performs 2-phase commit across up to 100 items/4MB data with all-or-nothing guarantees (costing 2x WCU). Cassandra LWT uses Paxos consensus per row condition (IF), adding 4 network roundtrips.
  6. DynamoDB charges per individual write operation (1 WCU per 1KB). High-throughput systems (e.g., 200,000 write QPS) generate massive AWS billing. Self-hosted Cassandra/ScyllaDB running on NVMe instance clusters amortizes cost across hardware rather than per-request billing.
  7. DynamoDB Streams captures a time-ordered sequence of item-level modifications in near real-time (24-hour retention), allowing AWS Lambda or Kinesis applications to consume CDC events for search indexing, cache invalidation, or analytics.
  8. DAX is a fully managed, write-through in-memory cache proxy designed specifically for DynamoDB, providing microsecond read latency without requiring application code changes (uses DynamoDB SDK directly).
  9. DynamoDB automatically splits the 10GB partition into two new partitions, redistributing the sort keys evenly based on hash ranges without downtime.
  10. Cassandra requires manual or scheduled execution of nodetool repair (anti-entropy repair via Merkle tree comparison across nodes) to fix data drift from missed writes. DynamoDB handles storage verification and silent repair transparently in AWS background infrastructure.

8. Common Mistakes

  • Provisioning DynamoDB without partition key randomization, causing severe throughput throttling on hot partition keys.
  • Using DynamoDB GSI without realizing that backpressured GSI writes will throttle writes to the primary table.
  • Running self-hosted Cassandra without dedicated operations engineers to manage JVM garbage collection and SSTable compactions.
  • Attempting to perform ad-hoc scans on DynamoDB tables in latency-critical production paths.
  • Expecting ACID multi-table joins in DynamoDB; failing to use Single-Table Design patterns.

9. Keywords

DynamoDB, Cassandra, Partition Key, Sort Key, RCU, WCU, DAX, Global Tables, GSI, LSI, ProvisionedThroughputExceededException, Single-Table Design, nodetool repair, Anti-Entropy, Merkle Tree.

10. Cheat Sheet

  • Core Difference: Cassandra = Open-source self-hosted wide-column DB; DynamoDB = AWS fully managed serverless KV/Document DB.
  • Data Modeling: Both use Partition Key (node distribution) + Sort Key (on-disk ordering). Single-Table Design is standard for DynamoDB.
  • Scaling: DynamoDB auto-splits partitions (>10GB or >1000 WCU); Cassandra scales by adding nodes to hash ring.
  • Hot Key Risk: DynamoDB partition throttles at 1,000 WCU / 3,000 RCU per partition. Randomize partition keys.
  • Caching: DAX provides zero-code microsecond cache proxy in front of DynamoDB.
  • Cost Rule: DynamoDB is cheaper for variable/bursty traffic; Cassandra/ScyllaDB is significantly cheaper for massive continuous write streams.

11. Related Decisions