Cassandra vs DynamoDB

These two are cousins. Both descend from the same family of ideas — consistent hashing, replication across nodes, partition key plus sort order, model your queries before your data — and both are what you reach for when one relational primary can't take the writes. The difference is who carries the pager and how the bill is shaped. Cassandra is software you run: a masterless ring of nodes you size, repair, compact and upgrade, anywhere you like, with consistency you tune per query. DynamoDB is a service you rent: no nodes, no repair, no compaction, AWS only, priced per request or per provisioned unit. The deciding question: are you on AWS and willing to pay per request so nobody ever operates the cluster — or do you need to run it anywhere, or at a steady scale where owning hardware beats renting requests?

The Verdict#

On AWS, default to DynamoDB. Choose Cassandra when you must run outside one cloud, when steady write volume is large enough that nodes are much cheaper than requests and you have the team to run them, or when you need per-query tunable consistency across several self-managed datacenters.

🎯 Staff Move: "Both fit the data model, so the decision is operational. We're all-in on AWS and nobody on this team has run a Cassandra repair, so I'll take DynamoDB and pay per request. If this were 500K writes a second, 24/7, for years, I'd price a Cassandra cluster against the DynamoDB bill — but only with a team that's signed up to own it."

At a Glance#

How They Actually Differ#

Who Runs the Ring#

Cassandra is a ring of equal nodes. Each owns token ranges; every write goes to RF replicas chosen by the partition key's token; any node can coordinate any request. There is no leader to fail over — a node down means its replicas take the load and hints queue up for it. In exchange, you own everything a service would hide: node sizing, adding capacity before disks fill, streaming data to new nodes, upgrades one node at a time, JVM tuning, and above all repair.

DynamoDB has the same partitioning idea inside, but you never see a node. Partitions split and move automatically; replication across three availability zones is built in; there is no repair, no compaction, no upgrade window.

Who pays: with Cassandra, a database platform team pays every week in operations. With DynamoDB, the application team pays in modeling constraints and finance pays per request.

Tunable Consistency vs Fixed Choices#

Cassandra lets each request pick its consistency. With RF=3, writing and reading at QUORUM (2 of 3) guarantees overlap, so reads see the latest acknowledged write; ONE is faster and may be stale; LOCAL_QUORUM keeps quorum inside one datacenter so a cross-region link doesn't sit on the request path. This is powerful and easy to misuse — a team writing at ONE and reading at ONE has eventual consistency whether they meant to or not.

DynamoDB offers two read choices on the base table (strong or eventual, strong costing 2× the read units) and no choice on GSIs. Writes are always durable across AZs before acknowledgement. Fewer knobs, fewer ways to be wrong.

🎯 Staff Insight: Last write wins in Cassandra is decided by client- or coordinator-supplied timestamps. A node with a clock 2 seconds fast silently wins every conflict for 2 seconds. Keep clocks tight and avoid read-modify-write on the same cell from many writers.

Deletes, Tombstones and Repair#

This is the difference that surprises teams moving from DynamoDB to Cassandra. Cassandra never deletes in place; it writes a tombstone that shadows older data until compaction removes both — but only after gc_grace_seconds (10 days by default). Two consequences:

• Repair is mandatory. If a replica missed a delete and repair doesn't run within gc_grace_seconds, the tombstone is purged elsewhere and the missed replica's old value comes back — "zombie" data. Full or incremental repair on a schedule is a correctness requirement, not hygiene.
• Tombstone-heavy reads fail. A queue-like table where you insert and delete constantly makes reads scan thousands of tombstones; by default Cassandra warns at 1,000 and aborts the query at 100,000 tombstones per read.

DynamoDB deletes are deletes. TTL expiry runs in the background (typically within a few days of expiry), at no write cost, and there is nothing to repair.

Wide Partitions and Time Series#

Cassandra's storage engine is excellent at append-heavy, time-ordered data: partition by (sensor_id, day), cluster by timestamp, set a table TTL, and use time-window compaction so whole SSTables expire at once. That pattern is how many large telemetry, messaging and event histories are stored. A partition can hold millions of rows (keep it under ~100 MB).

DynamoDB handles the same model — partition key sensor#day, sort key timestamp — with two differences: each partition key value is capped at ~1,000 writes/s, so very hot series need write sharding; and storage cost per GB is higher than raw disk on your own nodes, which matters at hundreds of terabytes of mostly cold data.

The same message-history table in each:

-- Cassandra (CQL)
CREATE TABLE messages (
  channel_id  bigint,
  bucket      int,            -- 10-day time bucket keeps partitions under ~100 MB
  message_id  timeuuid,
  author_id   bigint,
  body        text,
  PRIMARY KEY ((channel_id, bucket), message_id)
) WITH CLUSTERING ORDER BY (message_id DESC)
  AND default_time_to_live = 0
  AND compaction = {'class': 'UnifiedCompactionStrategy'};
-- read: SELECT * FROM messages WHERE channel_id = ? AND bucket = ? LIMIT 50;   (LOCAL_QUORUM)

# DynamoDB
PK = "CH#<channel_id>#<bucket>"     SK = "<message_id as sortable ULID>"
attributes: author_id, body
read: Query PK = "CH#123#2026-40", ScanIndexForward = false, Limit = 50   (strongly consistent)
hot channel (> ~1,000 writes/s): add a shard suffix to PK and merge on read

Same keys, same thinking. What differs is everything around them: on Cassandra you choose the compaction strategy and run repair; on DynamoDB you choose a capacity mode and watch for throttles.

Where Each One Breaks#

Cassandra#

DynamoDB#

Zombie Data from a Skipped Repair#

day 0     node C is down for 3 hours during a network incident; hints expire before it returns
day 0     user deletes 40K old messages → tombstones written to A and B only (C missed them)
day 1-14  repair job has been failing silently since a config change two weeks ago
day 10    gc_grace_seconds (10 days) passes; compaction on A and B purges tombstones and data
day 15    read at ONE hits node C → deleted messages returned; read repair copies them back to A and B
day 15    support tickets: "deleted messages are back"
Detection repair-age-per-table alert (should page at > 7 days); tombstone/purge metrics
Fix       restore deletes from audit log; fix the repair schedule; alert on repair failures
Owner     DB platform team (repair), with the app team re-issuing deletes

DynamoDB has no equivalent failure: there is no repair to skip. That absence is a large part of what you pay for.

The production surprise: Cassandra failures are slow and operational (repair debt, compaction backlog, disks filling over weeks). DynamoDB failures are fast and design-level (one hot key, one missing index). Cassandra rewards a team that watches dashboards weekly; DynamoDB rewards a team that reviews data models carefully once.

Cost and Operations#

Cassandra capacity rules of thumb that interviewers like to hear:

Rough break-even. 200,000 writes/s of 1 KB, steady, 24/7:

DynamoDB on-demand:   200K × 2.59M s ≈ 518B WRU/month × $0.625/M ≈ $324K/month (writes only, us-east-1, as of 2026)
DynamoDB provisioned: same load on provisioned capacity with reserved pricing is a fraction of that —
                      typically several times cheaper than on-demand at steady utilisation
Cassandra:            ~10–20K writes/s per node → 15–30 nodes at RF=3 with headroom, plus 2 engineers;
                      tens of thousands of $/month in instances and storage, plus salaries

At this scale, self-run Cassandra can be several times cheaper than on-demand DynamoDB, and the gap to provisioned-and-reserved DynamoDB is much smaller. At 2,000 writes/s the comparison flips completely: DynamoDB costs a few thousand dollars a month on-demand (much less provisioned) and Cassandra still needs a minimum cluster and a person.

🧭 Principal Insight: "The real comparison isn't Cassandra nodes versus DynamoDB requests — it's DynamoDB requests versus Cassandra nodes plus the two engineers who keep repair running. Below a few hundred thousand dollars a month of DynamoDB spend, those engineers are almost always better spent on the product."

Switching Later#

One-way doors: partition key design on either system (a change rewrites every row); Cassandra replication topology across datacenters; DynamoDB global table consistency mode. Two-way doors: DynamoDB capacity mode; Cassandra compaction strategy per table; node instance type.

How Real Companies Chose#

Discord: Outgrew Its Cassandra Operations, Stayed on the Data Model#

By 2022 Discord stored trillions of messages on a 177-node Cassandra cluster and described it as a heavy operational burden: hot partitions from busy channels causing cascading latency, JVM garbage-collection pauses, and compaction backlogs that required taking nodes out of rotation. They moved to ScyllaDB — a Cassandra-compatible engine — on 72 nodes, with p99 for historical reads going from 40–125 ms to about 15 ms and inserts from 5–70 ms to a steady 5 ms. They also added Rust data services in front that coalesce concurrent requests for the same data (Discord Blog).

Staff insight: Discord kept the wide-column data model and self-hosting; what they changed was the engine's operational profile. The hot-partition problem they fixed with request coalescing in front of the database — no storage engine removes the need to protect a hot key.

Heroku: Self-Run Cassandra to DynamoDB#

In an AWS-published case study, Heroku describes moving its metrics-as-a-service platform — about 30 TB, hundreds of thousands of observations per second — from self-managed Cassandra on EC2 to DynamoDB. The small database team wanted to stop operating clusters; they ran both paths in parallel, ramping shadow queries to 100% before cutting over, and report p99 spikes of ~80 ms on Cassandra versus consistently under 20 ms on DynamoDB, with operational overhead reduced by up to 90% (AWS Database Blog).

Staff insight: The trigger was team size, not scale. A small team running a distributed database spends its time on the database instead of the product. (It is a vendor-published story; the shape of the decision is the useful part.)

Amazon: The Managed End of the Spectrum#

The 2022 USENIX paper on DynamoDB describes a service designed for predictable performance in a multi-tenant system, with partitions split and moved automatically, and reports a peak of 89.2 million requests per second during Prime Day 2021 (USENIX ATC '22). By Prime Day 2025, AWS reported a peak of 151 million requests per second (AWS News Blog).

Staff insight: The paper's emphasis is predictability, not raw speed — consistent latency while the service rebalances under you. That is the thing you are buying instead of a Cassandra operations team.

Follow-Ups to Expect#

What to Say in the Interview#

"Cassandra and DynamoDB take the same data model — I'll design partition and sort keys the same way for either. The choice is who operates it and how we pay."

"We're on AWS with no database operations team, so DynamoDB. If this were 200K writes a second, steady, for years, I'd price a Cassandra cluster plus two engineers against provisioned DynamoDB before committing."

"If we do run Cassandra, repair runs on a schedule shorter than gc_grace_seconds and someone is paged when it doesn't — otherwise deleted data comes back."

"Either way, the hottest channel gets request coalescing in front of the database, because no storage engine makes one partition key infinitely fast."

Related Guides#

• Cassandra — ring, consistency levels, compaction and repair in depth
• DynamoDB — key design, GSIs, capacity modes and global tables
• Postgres vs DynamoDB — when the question is relational vs key-value
• Design a Replicated Key-Value Store — the shared design ideas behind both
• Design a Chat App — message history, the classic wide-partition workload
• Consistency, CAP and PACELC — quorums and tunable consistency
• Partitioning — partition keys, hot spots and rebalancing
• Time-Series Databases — when the workload is mostly metrics