Cassandra

What is Cassandra?

Apache Cassandra is a distributed wide-column database engineered for two things: enormous write throughput and no single point of failure. It’s masterless — every node is equal, there’s no primary to lose — data is distributed with consistent hashing, and its LSM-tree storage engine makes writes blazingly fast. It runs the write-heavy backends of companies operating at scale (messaging, time-series, event logging, IoT), and its design philosophy — availability and partition tolerance over strict consistency — is the textbook example of the CAP theorem’s tradeoffs made concrete.

Query-first data modeling — the thing that breaks teams

Cassandra punishes relational instincts. You do not model your data and then write queries; you start from the queries and model backwards, because Cassandra can only efficiently retrieve data by its partition key. There are no joins, no ad-hoc WHERE on arbitrary columns, no “I’ll add an index later” escape hatch that behaves like a relational index. The universal Cassandra mistake is designing tables like Postgres tables and then discovering that the query the business needs requires a full-cluster scan (an ALLOW FILTERING query — the performance foot-gun). Correct usage often means denormalizing the same data into multiple tables, one per query pattern — storage is cheap, and Cassandra’s whole premise is trading storage and modeling discipline for write speed and scale.

Tunable consistency and the operational reality

Cassandra lets you choose consistency per query — from “acknowledge one replica” (fast, may read stale) to “acknowledge a quorum” (consistent, slower) — the practical expression of AP-vs-CP tradeoffs. Operationally, it’s LSM-tree reality writ large: compaction tuning is critical, tombstones (deletion markers) accumulate and can wreck read performance if you delete heavily, and repair processes must run to maintain consistency across replicas. ScyllaDB is a C++ reimplementation offering the same model at higher per-node performance.

What people get wrong

• Relational modeling — designing normalized tables, then hitting ALLOW FILTERING scans for queries the partition key doesn’t serve.
• Heavy deletes: tombstone buildup silently destroys read latency; Cassandra is not built for delete-heavy workloads.
• Choosing it for the wrong shape: Cassandra shines at write-heavy, known-access-pattern scale — not ad-hoc analytics or transactional joins.

Primary source: Apache Cassandra documentation