What is Apache Cassandra^®?

Apache Cassandra use cases

Cassandra is useful when an application needs to keep storing and retrieving data as the workload grows across many users or devices. The following examples show how the database can support those applications and what needs to be considered in the design.

IoT and time-series data

A fleet operator might collect a vehicle's location throughout the day and let a dispatcher retrieve the last hour of its journey. Cassandra can distribute writes across vehicles while keeping each vehicle's readings grouped by a time window. That gives the dispatcher a query over the relevant records without scanning the whole fleet. The time-series data guide explains how to choose time buckets so one device's history does not grow into an unbounded partition.

Messaging and conversation history

A messaging application needs to load the latest messages when someone opens a conversation and retrieve older messages as they scroll back. Grouping messages by conversation and time bucket lets Cassandra serve that access pattern while distributing different conversations across the cluster. A very busy conversation can still concentrate traffic on a small set of replicas and needs separate testing. Message delivery and full-text search require additional application components beyond storing the conversation history.

Customer activity and order history

An online shop might need to show a customer's recent purchases while its support team looks up the delivery history for a particular order. Cassandra can store a customer-based view alongside an order-based view so each request reads the records it needs. The application or ingestion pipeline must keep those views updated. The transaction requirements for reserving stock or taking a payment need to be addressed separately from storing the order history.

Multi-region customer profiles

A service with applications in Europe and North America can keep replicas of customer preferences in both regions so routine profile reads use nearby nodes. Cassandra allows replication to be configured per datacentre with consistency levels chosen for the application's requirements. Locally acknowledged writes may not yet be visible in the other region and concurrent updates need an agreed handling strategy. The multi-datacentre guide covers placement and request routing alongside failover considerations.

Tables and partition keys

Cassandra is a wide-column database whose tables have typed columns that applications read and update through the Cassandra Query Language (CQL). CQL will look familiar if you have used SQL although the table design starts with the queries you need to run.

Suppose an application needs the latest temperature readings for one sensor on one day. We can group those readings into a partition identified by device_id and reading_day. Within that partition the observed_at clustering column puts the readings in time order.

The application can retrieve sensor-17's readings without searching every sensor. A query for all devices above a temperature threshold needs a different access pattern that might involve another table or an appropriate index. The Cassandra data modelling guide covers how to make those choices.

A day is a convenient bucket for this example rather than a universal recommendation. A device producing millions of readings a day may need smaller buckets to keep partitions manageable.

A CQL example

A keyspace groups the tables and defines their replication settings. The example below was tested with Cassandra 5.0.8 on a single-node development cluster whose datacentre is called datacenter1.

The replication factor of 1 below is for the development example only and provides no replica redundancy. The architecture example in the next section uses three replicas.

CREATE KEYSPACE introduction
WITH replication = {
  'class': 'NetworkTopologyStrategy',
  'datacenter1': 1
};

CREATE TABLE introduction.readings_by_device_day (
  device_id text,
  reading_day date,
  observed_at timestamp,
  temperature_c decimal,
  PRIMARY KEY ((device_id, reading_day), observed_at)
) WITH CLUSTERING ORDER BY (observed_at DESC);

The double parentheses identify the two-column partition key. The timestamp is the clustering column and the DESC setting puts newer readings first. We can now insert the three readings from the table above.

INSERT INTO introduction.readings_by_device_day
  (device_id, reading_day, observed_at, temperature_c)
VALUES ('sensor-17', '2026-09-01', '2026-09-01T10:00:00Z', 21.4);

INSERT INTO introduction.readings_by_device_day
  (device_id, reading_day, observed_at, temperature_c)
VALUES ('sensor-17', '2026-09-01', '2026-09-01T10:01:00Z', 21.6);

INSERT INTO introduction.readings_by_device_day
  (device_id, reading_day, observed_at, temperature_c)
VALUES ('sensor-18', '2026-09-01', '2026-09-01T10:00:00Z', 19.8);

This query selects one partition and returns its two most recent readings.

SELECT observed_at, temperature_c
FROM introduction.readings_by_device_day
WHERE device_id = 'sensor-17'
  AND reading_day = '2026-09-01'
LIMIT 2;

You can run CQL in AxonOps Workbench or cqlsh against a development cluster. The CQL quickstart continues through creating and querying tables.

How Cassandra distributes and replicates data

A Cassandra server is called a node and a cluster contains several nodes working together. Cassandra hashes the partition key into a token that determines which nodes hold that partition. The partitioning documentation explains the token ranges and their placement.

The replication factor determines how many copies of each partition are stored. With a replication factor of three there are three replicas of sensor-17's partition on three different nodes. Adding more nodes distributes the partitions across more servers rather than giving every server a copy of every partition.

Any node can coordinate a normal read or write so application traffic does not depend on one permanent primary node. Drivers use cluster metadata to route requests efficiently. Our article on Transactional Cluster Metadata and CMS explains how metadata coordination is handled separately from serving application data.

Consistency and node failures

The consistency level controls how many replica responses a request needs before it succeeds. For the three-replica example above a QUORUM write waits for two acknowledgements. The third replica is still sent the write even though its acknowledgement is not required to complete the request.

A quorum read overlaps with a previously successful quorum write on the same replica set. Concurrent writes and read-modify-write operations need further consideration because quorum does not provide transaction isolation. Conditional operations use lightweight transactions with a different coordination protocol.

Multi-datacentre deployments also need to distinguish QUORUM from LOCAL_QUORUM. The latter uses a majority of replicas in the local datacentre. Our consistency guide covers those configurations and their failure behaviour.

How Cassandra writes data to disk

Each replica records a normal write in its commit log and updates an in-memory memtable. Memtables are later flushed into immutable files called SSTables. A read may need data from memory and several SSTables because later updates do not overwrite the older files in place.

Compaction merges SSTables and reconciles versions of the data. Deletions are represented by tombstones that must be retained long enough to prevent an older copy on another replica from reappearing. The storage engine guide follows the read and write paths in more detail.

Compaction uses disk bandwidth and CPU alongside application requests. Repair addresses differences between replicas and backups provide a way to recover deleted or damaged data. Each job needs capacity and a schedule suited to the workload.

When should you choose Cassandra?

Cassandra is worth evaluating when you can spread the workload across many partition keys and need availability through individual node failures. It is particularly useful when data volume or geographic distribution requires more than one database server.

• Start with the queries. Work out which partition keys the application knows and how much data each request needs to read.
• Test the busy partitions. Adding nodes does not split one heavily used partition across an unlimited number of replicas.
• Check the transaction requirements. SQL-like syntax does not provide relational joins or make every CQL operation a multi-table transaction.
• Include the operational work. A representative test needs compaction and repair running alongside the application traffic.

A relational database may be a simpler choice for applications centred on joins and changing ad hoc queries. Cassandra can support additional access patterns through indexing although an index still needs testing against the amount of data the query will examine.

Apache Kafka serves a different purpose by moving and retaining streams of events. An application can use Kafka to carry sensor readings and Cassandra to serve queries over those readings. Our Kafka-to-Cassandra example shows that combination.

Operating Cassandra with AxonOps

Once an application depends on Cassandra you need to know whether requests are slowing down and whether the cluster can recover from a failure. That includes understanding table activity alongside disk usage and the progress of maintenance work.

AxonOps brings Cassandra monitoring together with repair and backup management. Its dashboards organise the metrics by operational area so you can investigate a problem without having to build every view yourself.

• Investigate Cassandra latency using request and storage measurements.
• Understand Adaptive Repair and how AxonOps regulates repair work against cluster load.
• Restore an AxonOps backup to a separate cluster with the required node and token mapping.

Explore AxonOps for Apache Cassandra