Partitioners

A partitioner distributes data in groups of rows (by partition key) across nodes in a cluster.

The partitioner function derives a token from the partition key, typically through hashing. The cluster distributes each row of data based on the token value. This distribution works even if the tables use different partition keys, such as user names or timestamps. Because each part of the hash range receives an equal number of rows on average, the read and write requests to the cluster are evenly distributed and load balancing is simplified. For more information, see Consistent hashing.

You can assign tokens manually or automatically, depending on the token allocation architecture:

Configure partitioner in cassandra.yaml.

When adding nodes to a cluster, you must use the same partitioner as the existing nodes.

If you change the partitioner for an existing cluster, you must reload all data (for example, from a snapshot). Otherwise, all existing data becomes inaccessible and effectively lost.

The following partitioners are available:

Murmur3Partitioner (default, recommended)

DataStax recommends this partitioner for new clusters, and it is required to enable vnodes with replication-balanced token allocation. Legacy partitioners are included for backwards compatibility only.

This partitioner uniformly distributes data across the cluster based on MurmurHash hash values. This hashing function creates a 64-bit hash value of the partition key with a possible range from -263 to +263-1.

When using this partitioner, you can page through all rows using the TOKEN() function in a CQL query.

Legacy partitioners

RandomPartitioner, ByteOrderedPartitioner, and OrderPreservingPartitioner are legacy partitioners included for backwards compatibility only. Use the Murmur3Partitioner for new clusters.

The RandomPartitioner uniformly distributes data evenly across the nodes using an MD5 hash value of the row key. The possible range of hash values is from 0 to 2127-1. Because it uses a cryptographic hash, which isn’t required by the database, it takes longer to generate the hash value than the Murmur3Partitioner. When using this partitioner, you can page through all rows using the TOKEN() function in a CQL query.

The ByteOrderedPartitioner orders rows lexically by key bytes. It requires significant administrative overhead to load balance the cluster, sequential writes can cause hot spots, and balancing for one table can result in uneven distribution for another table in the same cluster.

Bring-your-own partitioner

You can use any IPartitioner, including your own, as long as it is in the classpath. However, DataStax recommends the default Murmur3Partitioner.

Was this helpful?

Give Feedback

How can we improve the documentation?

© Copyright IBM Corporation 2026 | Privacy policy | Terms of use Manage Privacy Choices

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries. Kubernetes is the registered trademark of the Linux Foundation.

General Inquiries: Contact IBM