In short
When an app writes huge amounts of data across many machines and can't afford downtime, teams often reach for Apache Cassandra. Here's how it thinks.
A wide-column NoSQL database built for massive write throughput and multi-datacenter replication — used by companies operating at extreme scale (originally built at Facebook).

Think of it like this
A ring of ticket counters
Picture a station with booths in a circle. Your ticket's number decides which booth stores it, and neighbours keep copies. If one booth shuts for lunch, a neighbour still has your ticket. There's no head booth that can fail. That's Cassandra's ring.
Watch it happen
One write, many copies
INSERT (sensor 9)
1/6The app can send a write to any node. Node A becomes the coordinator for it.
The big ideas
What you need to know
No leader
Every node is equal and any node can take reads and writes, so there's no single point of failure.
Partition key decides placement
The partition key is hashed to pick which nodes store a row. Queries usually must include it.
Tunable consistency
Choose per query how many replicas must answer: ONE for speed, QUORUM for safety.
One table per query
No joins and limited filtering. You often create a table for each query, duplicating data on purpose.
See it in code
Walk through the code
1CREATE TABLE readings_by_sensor (2 sensor_id int,3 day date,4 ts timestamp,5 temp float,6 PRIMARY KEY ((sensor_id, day), ts)7) WITH CLUSTERING ORDER BY (ts DESC);8 9-- Fast: includes the full partition key10SELECT ts, temp FROM readings_by_sensor11WHERE sensor_id = 9 AND day = '2026-10-27' LIMIT 100;1/3(sensor_id, day) is the partition key: one sensor's day of readings lives together.
This is CQL, Cassandra's SQL-like language. It looks familiar, but there are no joins and WHERE must follow the key design.
Save yourself the pain
Common mistakes
Oops
Querying by a column that isn't part of the primary key.
Do this instead
Cassandra rejects it or needs ALLOW FILTERING, which scans. Create another table shaped for that query.
Oops
Picking Cassandra for a small app full of relations.
Do this instead
It shines with heavy writes across many nodes. For a few lakh rows with joins, Postgres is far simpler.
Your mission
Try Cassandra locally
Quick check
In Cassandra, why must most queries include the partition key?
Go deeper
- 1Read a high-level overview of Cassandra's architecture — no master node, eventual consistency.
- 2Understand its trade-off: extreme write scalability in exchange for weaker consistency guarantees.
- 3Recognize this is a specialized tool — most projects will never need it.
More topics at this stop
Stuck on this topic? Ask an Insider
Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.