How to do Partitioning in Cassandra?

To do partitioning in Apache Cassandra, you define a partition key inside your table’s PRIMARY KEY clause when creating the table in CQL. Cassandra hashes this key to determine which node in the cluster stores the data.

Photo by Prasopchok on Unsplash

1. Define the Partition Key in CQL

Unlike relational databases where partitioning is often added later as an administrative task, partitioning in Cassandra is mandatory and built directly into your table schema. [1, 2]

• Simple Partition Key. Use a single column as the first element of the PRIMARY KEY to group rows by that value.

CREATE TABLE users_by_country (
    country text,
    user_id uuid,
    name text,
    PRIMARY KEY (country, user_id)
);

(Here, country is the partition key, and user_id is a clustering column that sorts rows inside that partition.)

• Composite Partition Key. Wrap multiple columns in extra parentheses ((...)) to combine them into a single partition key. This technique prevents a single partition from growing too large.

CREATE TABLE sensor_logs (
    sensor_id text,
    bucket_date date,
    event_time timestamp,
    reading double,
    PRIMARY KEY ((sensor_id, bucket_date), event_time)
) WITH CLUSTERING ORDER BY (event_time DESC);

• (Here, sensor_id and bucket_date together determine which node holds the data, while event_time sorts the readings within that daily bucket.)

2. Configure the Cluster Partitioner (Optional)

Get Harshvardhan Sinha’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

At the cluster level, Cassandra uses a partitioner algorithm configured in the cassandra.yaml file to hash partition keys into 64-bit integer tokens.

• Murmur3Partitioner. This is the default partitioner in modern Cassandra and uses a fast MurmurHash function to spread data evenly across all nodes.
• RandomPartitioner and ByteOrderedPartitioner. Legacy or specialized options that distribute data via MD5 hashes or lexical byte order. Avoid changing the default unless migrating an older cluster, as changing partitioners requires reloading all cluster data.

3. Best Practices for Choosing a Partition Key

Because Cassandra relies on query-driven data modeling, design your partition keys using these guidelines from the Apache Cassandra Data Modeling Documentation and ScyllaDB’s Partition Key Guide:

• Match your WHERE clause. Always include the full partition key in your SELECT queries. Querying without it forces Cassandra to scan every node in the cluster, which severely degrades performance.
• Keep partitions under 100 MB. Very large partitions create memory pressure and slow down compaction and repairs. Use time-bucketing (such as adding year_month or date to a composite key) to keep partition sizes bounded.
• Ensure high cardinality. Choose keys with many distinct values (like user_id or device_id) rather than low-cardinality fields (like status or gender) so data distributes evenly without creating "hotspots" on a single node.

Effective partitioning in Apache Cassandra comes down to designing your PRIMARY KEY around your exact query patterns rather than treating it as an afterthought. By combining high-cardinality partition keys with time-bucketing strategies, you ensure that data spreads evenly across your cluster and reads remain fast as your dataset scales.

Core takeaway. Always align your partition key with your WHERE clauses so Cassandra can locate data in a single hop.

Key safeguard. Use composite keys or time buckets to keep individual partitions under 100 MB and prevent node hotspots.