Apache Cassandra

Cassandra vs RDBMS Trade-offs

Articulate the fundamental architectural and modeling trade-offs between Cassandra and traditional relational databases.

Choosing between Cassandra and a traditional RDBMS (like PostgreSQL or MySQL) is fundamentally a decision about which guarantees and query patterns matter most for a given application, since the two systems make deliberately opposite trade-offs across several dimensions.

An RDBMS is like a single, meticulously organized central library with a full card catalog letting you cross-reference anything against anything else, but only one librarian can update the catalog at a time. Cassandra is like a global chain of libraries, each with quick,独立 local checkout counters that never wait for a central authority, at the cost of each branch needing its own pre-organized, purpose-built shelf for every specific type of request you expect people to make.

Key Concepts

1
Relational databases are optimized for strong consistency, ACID transactions, and flexible ad-hoc querying via JOINs and normalized schemas, typically scaling vertically (bigger machines) or via more complex horizontal sharding solutions bolted on afterward. Cassandra is optimized for horizontal scalability, high write throughput, and continuous availability across many commodity nodes and even multiple datacenters, at the cost of requiring denormalized, query-first schema design and offering only tunable (not default strong) consistency.
strong consistency, ACID transactions, and flexible ad-hoc queryinghorizontal scalability, high write throughput, and continuous availability
2
In CAP theorem terms, traditional RDBMS setups (especially single-node or synchronously-replicated ones) tend to prioritize consistency, while Cassandra defaults to prioritizing availability and partition tolerance, though tunable consistency lets you dial toward stronger consistency per-operation at the cost of availability/latency for that operation.
3
A common interview framing is that Cassandra excels at "write-heavy, high-volume, denormalized, query-pattern-known-in-advance" workloads like IoT data, messaging, and time-series, while an RDBMS remains the better fit for workloads needing complex ad-hoc joins, strict multi-row/multi-table transactions, or smaller datasets where operational simplicity outweighs horizontal scale needs.