Cassandra — Wide-Column at Planet Scale

Cassandra's core insight: every node is equal, every write goes to memory first, and the ring topology means adding a new machine automatically absorbs part of the load — no resharding ceremony required.

Let's walk through a concrete scenario. No Cassandra knowledge required yet — just follow the numbers and feel the pain point.

The situation: a global sensor network

You are building a telemetry platform for industrial IoT sensors. Each sensor reports temperature, pressure, and vibration readings 100 times per second. You start with 10,000 sensors. That is 1,000,000 writes per second — one million rows landing in your database every second of every day.

You try Postgres first, because you know SQL and it works great for everything else you have built. Here is what happens:

• A single Postgres node can handle roughly 10,000–30,000 writes per second under favorable conditions.
• At 1M writes/sec you need 30–100 Postgres nodes just to absorb the load.
• Sharding Postgres is manual work: you pick a shard key, you route writes in application code, and when you outgrow your shard count you go through a painful re-sharding migration where you move data around while staying live.
• Six months later your sensor count grows to 50M — now you need 5× as many shards. Re-shard ceremony again. And again next year.

The re-sharding problem is not a Postgres bug. It is a fundamental property of any system not designed for horizontal elasticity. You are bolting distribution onto a system built for a single powerful machine.

Why Cassandra changes the equation

Cassandra treats sharding as a first-class feature, not an afterthought. From the moment you create your first table, your data is automatically distributed across however many nodes you have using consistent hashing. When you add a new node, Cassandra automatically transfers a share of the token range from existing nodes to the new one — no application code changes, no downtime, no migration script.

The practical effect: scaling from 10M sensors to 50M sensors means adding machines to the cluster. Cassandra handles the rest. Your application never needs to know how many nodes exist.

The trade you make

Cassandra's write performance comes from a specific design choice: writes go to an in-memory structure (Memtable) plus a commit log, then are flushed to immutable files on disk (SSTables) in the background. There are no in-place row updates — every change is a new timestamped entry. Reads are more work because Cassandra may need to merge multiple SSTables and check for tombstones (deletion markers). The conclusion: Cassandra is optimized for write-heavy workloads where you know your access patterns up front. For complex ad-hoc queries, analytics, or ACID transactions, a relational database or a warehouse will serve you better.

Before looking at any CQL syntax, you need one mental picture burned in permanently: the ring. Every design decision in Cassandra makes sense once you understand the ring. Without it, the partition key, replication factor, and consistency levels feel like arbitrary rules.

The ring explained simply

Imagine a circular number line from 0 to 1,023 (Cassandra actually uses a much larger range — around −2⁶³ to 2⁶³ − 1 — but the concept is the same). Each Cassandra node is assigned responsibility for a range of numbers on that circle. When you write a row, Cassandra hashes your partition key to produce a number (called a token). Then it walks clockwise around the ring until it finds the first node whose range includes that token. That node stores the row. Simple.

Replication works the same way. If your replication factor is 3, the row is stored on three consecutive nodes clockwise from the token. Node 1 fails? Nodes 2 and 3 still have the data. The cluster keeps serving requests without any failover script.

Four design heuristics that flow from the ring

Once you picture the ring, four key ideas click into place:

Before writing a single CQL statement you need to feel comfortable with six concepts. Each one maps to a very concrete thing — there is no hand-waving here.

The phrase "wide-column database" sounds intimidating. In practice it means one thing: a partition (identified by the partition key) can hold a very large number of rows, all sorted together on disk. Think of each partition as its own mini-sorted-table, stored contiguously on one node. Different partitions live on different nodes, but within a partition everything is local and sorted.

The two-part primary key — the most important concept in CQL

In SQL, a primary key uniquely identifies one row. In Cassandra, the primary key has two jobs:

1. Partition key — hashed to determine which node. All rows with the same partition key go to the same node.
2. Clustering key — determines the physical sort order of rows within a partition. This enables efficient range scans.

Together they look like: PRIMARY KEY ((sensor_id), recorded_at) — the inner parentheses mark the partition key; recorded_at is the clustering key. Multiple partition key columns are allowed (composite partition key), and multiple clustering keys too.

Three common schema patterns in CQL

-- Time-series: sensor readings bucketed by date + sensor
-- Why composite partition key? Without the date bucket,
-- one sensor_id could accumulate billions of rows in one
-- partition (unbounded growth). Bucketing by day caps a
-- partition at ~8.64M rows/day at 100 readings/sec.

CREATE TABLE sensor_readings (
  sensor_id   TEXT,
  date_bucket DATE,          -- partition key part 2: limits partition size
  recorded_at TIMESTAMP,     -- clustering key: sorts rows in time order
  temperature FLOAT,
  pressure    FLOAT,
  PRIMARY KEY ((sensor_id, date_bucket), recorded_at)
) WITH CLUSTERING ORDER BY (recorded_at DESC); -- newest first

-- Write:
INSERT INTO sensor_readings (sensor_id, date_bucket, recorded_at, temperature, pressure)
VALUES ('A-42', '2026-05-09', toTimestamp(now()), 21.3, 1013.2);

-- Read last 100 readings for sensor A-42 today (hits 1 partition, 1 node):
SELECT * FROM sensor_readings
WHERE sensor_id = 'A-42' AND date_bucket = '2026-05-09'
LIMIT 100;

-- User profile: simple lookup by username
-- Single-column partition key is fine here — one user = one partition.
-- No clustering key needed (only one row per user).

CREATE TABLE users (
  username    TEXT PRIMARY KEY,  -- shorthand: partition key only, no clustering key
  email       TEXT,
  display_name TEXT,
  created_at  TIMESTAMP,
  preferences MAP<TEXT, TEXT>   -- Cassandra supports map/list/set column types
);

-- Write:
INSERT INTO users (username, email, display_name, created_at)
VALUES ('rafikul', 'rafikul@example.com', 'Raf', toTimestamp(now()));

-- Read (routes to exactly 1 node — O(1)):
SELECT * FROM users WHERE username = 'rafikul';

-- Update is actually an upsert — Cassandra never locks a row:
UPDATE users SET display_name = 'Rafikul' WHERE username = 'rafikul';

-- Range query within a partition using clustering key
-- Scenario: fetch all orders for a user placed in a date range.
-- Partition key = user_id (routes all user orders to same node).
-- Clustering key = order_date DESC (newest first on disk).

CREATE TABLE orders_by_user (
  user_id    TEXT,
  order_date DATE,        -- clustering key 1 (for date range queries)
  order_id   UUID,        -- clustering key 2 (for uniqueness within a day)
  total      DECIMAL,
  status     TEXT,
  PRIMARY KEY (user_id, order_date, order_id)
) WITH CLUSTERING ORDER BY (order_date DESC, order_id DESC);

-- Range query — FAST because order_date is the clustering key:
SELECT * FROM orders_by_user
WHERE user_id = 'user-123'
  AND order_date >= '2026-01-01'
  AND order_date <= '2026-05-09';

-- Note: You CANNOT do WHERE status = 'PENDING' alone —
-- filtering non-key columns requires ALLOW FILTERING (slow scan).
-- The solution: create a separate table keyed by (user_id, status).

Here is the single biggest mindset shift you need to make when coming from SQL: in Cassandra, you design your tables around your queries, not around your data.

In SQL you normalize data — one table per entity, no duplication. When you need to answer a question, the database JOINs tables at query time to reconstruct the answer. The database engine handles the complexity of combining data from multiple tables. That is the relational model's superpower.

Cassandra has no JOIN operation. Zero. The reason is physical: your data is spread across dozens or hundreds of nodes. A JOIN would require coordinating between potentially hundreds of nodes on every query — the latency would be unbearable. Instead, Cassandra's answer is denormalization: you pre-compute the answer to each query and store it in its own table, shaped exactly the way the query needs it.

The four rules of query-first design

Cassandra copies every piece of data to multiple nodes automatically. This is called replication — and unlike MySQL primary/replica setups, all copies are equal. Any replica can answer reads or accept writes. There is no "master" to fail over from.

The Replication Factor (RF) tells Cassandra how many copies to keep. RF=3 means every row lives on 3 different nodes. If one node dies, 2 still have your data. If two die simultaneously, 1 still does. You typically need to lose all RF nodes at once before data becomes unavailable — which is why RF=3 is the production minimum and often the sweet spot.

Within each datacenter, Cassandra places replicas on different racks automatically — so a single rack power failure can't take out all copies. Cross-DC replication happens asynchronously; the local DC responds to clients immediately, and the remote DC catches up in the background.

Two Replication Strategies

CREATE KEYSPACE my_app
WITH replication = {
  'class': 'SimpleStrategy',
  'replication_factor': 3
};

CREATE KEYSPACE my_app
WITH replication = {
  'class': 'NetworkTopologyStrategy',
  'us-east': 3,
  'eu-west': 3
};

Every Cassandra read and write carries a consistency level — a number that says "how many replicas must confirm this operation before we call it done?" This is Cassandra's most powerful feature: you can dial safety vs. speed on a per-query basis. Most SQL databases give you one global setting and force you to choose between strong consistency everywhere or eventual consistency everywhere. Cassandra lets you choose for each individual query.

Think of it like a vote: with RF=3, you have 3 votes. Requiring 2 out of 3 to agree (quorum) means you can tolerate 1 disagreeing replica. Requiring all 3 is safest but slowest. Requiring just 1 is fastest but you might read stale data.

The R + W > N Formula

Here's the math that makes tunable consistency work: if the number of replicas that must acknowledge a write (W) plus the number that must respond to a read (R) is greater than the total replica count (N), then those two sets of replicas must overlap by at least one node. That overlapping node holds the latest write — so your read is always fresh. This is how you get strong consistency without a single primary.

In practice: RF=3, W=LOCAL_QUORUM (2), R=LOCAL_QUORUM (2): 2 + 2 = 4 > 3. Guaranteed overlap. The typical p99 write latency at LOCAL_QUORUM on commodity hardware is roughly 5–20 ms within a single datacenter.

# Python driver — consistency per-statement
from cassandra import ConsistencyLevel
from cassandra.query import SimpleStatement

stmt = SimpleStatement(
    "INSERT INTO orders (order_id, user_id, total) VALUES (%s, %s, %s)",
    consistency_level=ConsistencyLevel.LOCAL_QUORUM
)
session.execute(stmt, (order_id, user_id, total))
# Waits for 2/3 replicas in the local DC to confirm

stmt = SimpleStatement(
    "SELECT * FROM product_catalog WHERE product_id = %s",
    consistency_level=ConsistencyLevel.ONE
)
row = session.execute(stmt, (product_id,)).one()
# Returns immediately from nearest replica — may be slightly stale

# Strong consistency: R + W > N
# RF=3, W=LOCAL_QUORUM(2), R=LOCAL_QUORUM(2) → 4 > 3 ✓

write_stmt = SimpleStatement(
    "UPDATE inventory SET stock = %s WHERE sku = %s",
    consistency_level=ConsistencyLevel.LOCAL_QUORUM
)
read_stmt = SimpleStatement(
    "SELECT stock FROM inventory WHERE sku = %s",
    consistency_level=ConsistencyLevel.LOCAL_QUORUM
)
session.execute(write_stmt, (new_stock, sku))
row = session.execute(read_stmt, (sku,)).one()
# Guaranteed to see the write above ✓

Here's the secret behind Cassandra's write speed: writes never go directly to disk in random positions. Random disk writes are slow — even on SSDs. Instead, Cassandra layers three structures that turn random writes into sequential ones. This is called an LSM tree (Log-Structured Merge tree), and it's the same idea behind RocksDB, LevelDB, and HBase.

The Four Components

Imagine running an e-commerce platform. Your audit log absolutely cannot lose a row — you'd fail a compliance audit. Your product view counter, on the other hand, being off by a few counts for a few seconds is completely fine. Your user profile needs to be consistent within a datacenter but can lag slightly across continents. In most databases, you're forced to use the same consistency level for everything. Cassandra lets each of these workloads use the right level for it.

Cassandra is eventually consistent by default — but sometimes you genuinely need "if X is still true, do Y." Think of claiming a unique username: two users try to register "alice" simultaneously. Without any coordination, both succeed, and now you have two accounts with the same name. This is exactly the kind of problem Lightweight Transactions (LWT) solve.

LWT uses the Paxos consensus protocol — a distributed agreement algorithm — to coordinate across replicas. Before writing, Cassandra runs a four-phase protocol (prepare/promise, read, propose/accept, commit) to ensure all replicas agree on the current state of that row. Only then does the write proceed. This is robust, but expensive: roughly 4 round trips instead of 1, which translates to roughly 3–4× the latency of a normal write (Paxos v2 in Cassandra 4.1+ cuts this in half).

-- Reserve a username: only one client can win
INSERT INTO users (username, email, created_at)
VALUES ('alice', 'alice@example.com', toTimestamp(now()))
IF NOT EXISTS;

-- Check [applied] in your driver code:
-- Row(applied=True)  → success, username claimed
-- Row(applied=False) → username already taken

-- State machine transition: only move from 'pending' to 'confirmed'
UPDATE orders
SET status = 'confirmed', confirmed_at = toTimestamp(now())
WHERE order_id = 12345
IF status = 'pending';

-- If another process already changed status, [applied]=false
-- Your code should re-read and decide what to do next

-- Counter table definition (counters only — no regular columns)
CREATE TABLE page_views (
  page_id   text,
  day       date,
  views     counter,
  PRIMARY KEY (page_id, day)
);

-- Increment: safe to call from multiple nodes simultaneously
UPDATE page_views
SET views = views + 1
WHERE page_id = 'homepage' AND day = '2026-05-09';

-- Read (eventually consistent — may be slightly behind)
SELECT views FROM page_views
WHERE page_id = 'homepage' AND day = '2026-05-09';

In a relational database, you design the schema around the data model, then write whatever queries you need. In Cassandra, you do the opposite: you start with the queries and work backwards to the schema. Every table is essentially a pre-computed answer to a specific question. This sounds strange at first, but it becomes natural — and it's what makes Cassandra fast at scale.

The reason is physical: Cassandra can only efficiently read data within a single partition (one partition key) or do a range scan within a partition (using clustering columns). It cannot efficiently join two tables or filter on non-key columns across millions of partitions. So your schema must put the data a query needs in exactly the partition that query will hit.

Five Schema Patterns

-- Table: one partition per (sensor, month)
CREATE TABLE sensor_readings (
  sensor_id  text,
  year_month text,          -- e.g. '2026-05' — the bucket
  recorded_at timestamp,    -- clustering key: fine-grained ordering
  temperature float,
  humidity    float,
  PRIMARY KEY ((sensor_id, year_month), recorded_at)
) WITH CLUSTERING ORDER BY (recorded_at DESC);

-- Write: bucket is determined by application code
INSERT INTO sensor_readings
  (sensor_id, year_month, recorded_at, temperature, humidity)
VALUES
  ('sensor-42', '2026-05', toTimestamp(now()), 22.4, 58.1);

-- Query: last 30 days = just one partition scan
SELECT * FROM sensor_readings
WHERE sensor_id = 'sensor-42'
  AND year_month = '2026-05'
  AND recorded_at >= '2026-05-01'
LIMIT 1000;

-- Table 1: look up by user ID (primary access pattern)
CREATE TABLE users_by_id (
  user_id   uuid PRIMARY KEY,
  email     text,
  username  text,
  created_at timestamp
);

-- Table 2: look up by email (login flow)
CREATE TABLE users_by_email (
  email     text PRIMARY KEY,
  user_id   uuid,
  username  text
);

-- Application writes both atomically using BATCH
BEGIN BATCH
  INSERT INTO users_by_id   (user_id, email, username, created_at)
    VALUES (uuid(), 'alice@example.com', 'alice', toTimestamp(now()));
  INSERT INTO users_by_email (email, user_id, username)
    VALUES ('alice@example.com', uuid(), 'alice');
APPLY BATCH;

-- Main product table (by product ID)
CREATE TABLE products (
  product_id uuid PRIMARY KEY,
  name       text,
  price      decimal,
  category   text
);

-- Inverted index: category → product IDs
CREATE TABLE products_by_category (
  category   text,
  product_id uuid,
  name       text,
  price      decimal,
  PRIMARY KEY (category, product_id)
);

-- Application writes both on product creation
BEGIN BATCH
  INSERT INTO products (product_id, name, price, category)
    VALUES (uuid(), 'Wireless Mouse', 29.99, 'peripherals');
  INSERT INTO products_by_category (category, product_id, name, price)
    VALUES ('peripherals', uuid(), 'Wireless Mouse', 29.99);
APPLY BATCH;

-- Query by category: single partition read, fast
SELECT * FROM products_by_category
WHERE category = 'peripherals'
LIMIT 50;

Every time Cassandra flushes data from memory to disk it creates a new immutable file called an SSTable. Left unchecked, dozens of SSTables pile up on disk. A read then has to check every single one to find all versions of a row — that's called read amplification, and it makes reads painfully slow. Compaction is Cassandra's housekeeping job: it merges SSTables together, applies tombstone deletions, and produces fewer, cleaner files. The strategy you pick tells Cassandra how to choose which files to merge.

The Four Strategies

In most databases, DELETE means the row is gone immediately. In Cassandra, DELETE is a lie — or at least a delayed truth. Cassandra is append-only by design: every node writes data forward, never backwards. When you delete a row, Cassandra writes a special marker called a tombstone that says "this data is dead." The actual bytes sit on disk until compaction + a safety window (gc_grace_seconds) pass. Understanding tombstones is crucial because misusing them is one of the top causes of Cassandra performance disasters.

Why the 10-day grace period?

Imagine a replica node goes offline for a week. While it's down, a DELETE happens on the rest of the cluster. The replica comes back, and Cassandra runs repair to sync it. If the tombstone were already gone, the repair would just re-add the deleted row — a zombie resurrection. The gc_grace_seconds window gives every replica a safe period to learn about tombstones before they vanish. This is why you should never allow a node to be down longer than gc_grace_seconds before running repair.

The Tombstone Graveyard Anti-Pattern

The most damaging tombstone problem comes from treating Cassandra like a queue: constantly insert rows, then delete them after processing. The result is a partition that contains mostly tombstones. Reads have to scan all those dead markers to confirm no live rows exist underneath — Cassandra doesn't short-circuit this. Queries scanning more than roughly 1,000 tombstones emit a warning in the logs. Queries scanning more than roughly 100,000 tombstones are automatically aborted by default. That threshold is lower than you think for a busy partition.

Three Mitigation Patterns

A Cassandra partition is all the rows that share the same partition key. If your table has PRIMARY KEY (user_id, event_time), then every row for user_id = 42 lives in the same partition — and that partition lives entirely on the same set of replica nodes. This is what makes reads fast: one network hop to the right node, then a sequential scan within the partition. The problem arises when one partition key attracts vastly more data than others, creating a hot partition: a single node drowns while the rest sit idle.

A partition over roughly 100 MB or 100,000 rows starts attracting operational problems: reads slow down, repair takes longer, streaming during node replacement takes longer. A partition over ~1 GB is genuinely painful to operate. Design your partition keys to keep partitions well-bounded before you have data — retrofitting this is hard.

Four Strategies for Bounded Partitions

PRIMARY KEY ((user_id, year_month), event_time)

Cassandra's performance ceiling is mostly determined by three things: schema design (the most important), consistency level (fewer replicas queried = faster but less safe), and hardware (SSDs are effectively mandatory for production). JVM and daemon tuning then let you squeeze the last bit of performance from your hardware. Here are the five most impactful levers operators reach for.

The Five Tuning Levers

Cassandra is famous for availability — but that availability requires active maintenance. Unlike managed SQL databases where the cloud provider handles backups and upgrades, Cassandra clusters need deliberate operational care. The six areas below cover what you'll actually spend time on in production. The good news: Cassandra's nodetool CLI gives you direct access to most of these operations without cluster downtime.

Cassandra occupies a specific niche: massive write throughput, global distribution, no single point of failure, predictable latency at scale. Other databases cover overlapping territory but make different trade-offs. Knowing which tool fits which problem is more valuable than knowing any one tool deeply — the wrong database choice is expensive to undo.

Five Alternatives at a Glance

Cassandra has a well-rounded toolbox for every phase of development and operations. You will use the CQL shell to explore and prototype, the nodetool CLI to check cluster health and run maintenance tasks, the official DataStax drivers to connect from your application code, and a cloud-hosted option when you want all of this without managing servers yourself. Here is the rundown of the six tools you will reach for most.

-- Connect to a local Cassandra node (default port 9042)
cqlsh

-- Or connect to a remote node with credentials
cqlsh my-cassandra.example.com 9042 -u cassandra -p mypassword

-- Create a keyspace (use NetworkTopologyStrategy in production)
CREATE KEYSPACE IF NOT EXISTS events
  WITH replication = {
    'class': 'NetworkTopologyStrategy',
    'datacenter1': 3   -- 3 replicas in datacenter1
  };

USE events;

-- Create a time-series table (partition by sensor, cluster by time DESC)
CREATE TABLE IF NOT EXISTS readings (
  sensor_id   UUID,
  recorded_at TIMESTAMP,
  value       DOUBLE,
  unit        TEXT,
  PRIMARY KEY (sensor_id, recorded_at)
) WITH CLUSTERING ORDER BY (recorded_at DESC);

-- Insert a row
INSERT INTO readings (sensor_id, recorded_at, value, unit)
VALUES (uuid(), toTimestamp(now()), 22.4, 'celsius');

-- Query the latest 10 readings for a sensor (fast: single partition)
SELECT recorded_at, value, unit
FROM readings
WHERE sensor_id = 550e8400-e29b-41d4-a716-446655440000
LIMIT 10;

-- Inspect schema
DESCRIBE TABLE readings;

-- Explore cluster topology
DESCRIBE CLUSTER;

from cassandra.cluster import Cluster
from cassandra.auth import PlainTextAuthProvider
from cassandra.policies import DCAwareRoundRobinPolicy
import os

# One Cluster + one Session — reuse across the application
auth = PlainTextAuthProvider(
    username=os.environ["CASS_USER"],
    password=os.environ["CASS_PASS"],
)
cluster = Cluster(
    contact_points=[os.environ["CASS_HOST"]],
    auth_provider=auth,
    load_balancing_policy=DCAwareRoundRobinPolicy(local_dc="datacenter1"),
)
session = cluster.connect("events")

# --- Prepared statement (prepare once, execute many times) ---
INSERT_READING = session.prepare("""
    INSERT INTO readings (sensor_id, recorded_at, value, unit)
    VALUES (?, ?, ?, ?)
""")

GET_LATEST = session.prepare("""
    SELECT recorded_at, value, unit
    FROM readings
    WHERE sensor_id = ?
    LIMIT ?
""")

def record_reading(sensor_id, ts, value, unit):
    """Write-heavy: Cassandra shines here."""
    session.execute(INSERT_READING, (sensor_id, ts, value, unit))

def get_latest(sensor_id, n=10):
    """Fast single-partition query — O(log N) in partition."""
    rows = session.execute(GET_LATEST, (sensor_id, n))
    return [{"ts": r.recorded_at, "val": r.value, "unit": r.unit} for r in rows]

# --- Batch insert (same partition only — mixed partitions = anti-pattern) ---
from cassandra.query import BatchStatement, BatchType

def bulk_insert(sensor_id, readings):
    """Only use batch when all rows share the same partition key."""
    batch = BatchStatement(batch_type=BatchType.UNLOGGED)
    for ts, value, unit in readings:
        batch.add(INSERT_READING, (sensor_id, ts, value, unit))
    session.execute(batch)

# ── CLUSTER HEALTH ──────────────────────────────────────────────────────
# Quick overall view: node states, load, token ownership
nodetool status

# Verbose: shows address, rack, DC, token ownership per node
nodetool status --resolve-ip

# ── MAINTENANCE ─────────────────────────────────────────────────────────
# Run repair on a keyspace (sync replicas, fix drift — schedule WEEKLY)
nodetool repair events

# Repair a specific table only
nodetool repair events readings

# Force a memtable flush to SSTables (run before a snapshot or restart)
nodetool flush events readings

# ── BACKUPS ─────────────────────────────────────────────────────────────
# Create a snapshot (hard-links SSTable files — instant, space-efficient)
nodetool snapshot --tag my-snapshot-2026-05-09 events

# List all snapshots
nodetool listsnapshots

# Clear a snapshot when done (free the hard-linked space)
nodetool clearsnapshot --tag my-snapshot-2026-05-09

# ── PERFORMANCE INVESTIGATION ────────────────────────────────────────────
# Thread pool saturation (look for Pending > 0 in any stage)
nodetool tpstats

# Ongoing compaction jobs (how much I/O is compaction eating?)
nodetool compactionstats

# Current reads/writes per second, latency percentiles
nodetool tablestats events.readings

# ── DECOMMISSION / REPLACE ───────────────────────────────────────────────
# Gracefully remove THIS node from the ring (streams its data first)
nodetool decommission

Cassandra has a reputation built up over years — and parts of that reputation are out of date, oversimplified, or just plain wrong. The six beliefs below come up repeatedly in interviews, design reviews, and tech blog posts. Each one has a grain of truth, which is exactly why it persists. Knowing why each one is at least partly wrong is more useful than just memorising the correction.

These are real patterns drawn from widely-reported production failures and recurring incidents that Cassandra practitioners encounter repeatedly. Every one was preventable. Read them as the most concrete possible evidence that table design, compaction strategy, and operational habits are not abstract concerns — they are the difference between a five-minute fix and a multi-hour outage.

Everything on this page distils into eight practices. None of these are arbitrary rules — each one has a clear mechanical reason rooted in how Cassandra actually works. Follow them and you avoid the overwhelming majority of Cassandra production problems. Skip any one of them and you are relying on luck.

These are the questions engineers most commonly ask when they are evaluating Cassandra for the first time or debugging it in production. Plain English first, then the nuance that matters for real decisions.

Cassandra does not exist in isolation. The topics below are either the databases you will be asked to compare it against, the underlying concepts that explain why Cassandra works the way it does, or the complementary systems it is commonly deployed alongside. Work through them in the order that matches where you want to go next.