Consistency levels

The consistency level determines the number of replicas that must acknowledge a read or write operation as successful in order for a successful response to be returned to the client.

The Data API and clients always use the LOCAL_QUORUM consistency level for reads and writes. Cassandra Query Language (CQL) for Astra DB supports all read consistency levels, and it supports all write consistency levels except ONE, ANY, and LOCAL_ONE.

LOCAL_QUORUM is generally sufficient for balanced workloads due to Astra DB’s eventual consistency model. It has lower latency than multi-region consistency levels because it only requires acknowledgement from replicas in the target read/write region.

If you want to ensure that a write request has written to all of a database’s regions before considering it successful, you might use EACH_QUORUM, SERIAL, or ALL. However, these consistency levels have higher latency than LOCAL_QUORUM because they require acknowledgement from replicas in all regions. ALL has the highest latency because it requires acknowledgement from all replicas in all regions.

You can set consistency levels for a client session, individual read/write requests, or globally. For application development, set the consistency level with your Apache Cassandra driver. For example, using the Java driver, call QueryBuilder.insertInto with setConsistencyLevel to set a per-insert consistency level. With the CQL shell (cqlsh), you can use the CONSISTENCY command to set the consistency level for all queries in the current cqlsh session.

Write consistency levels

The write consistency level specifies how many replicas must respond to a write request before the write is considered successful. If the database cannot distribute the write to enough replicas to meet the requested consistency level, it returns an Unavailable exception and does not perform any writes. This occurs when too many replicas are down or unreachable. For example, a write at ALL fails if any node is down. If there are enough replicas available but the writes aren’t completed within the timeout window, the database returns a WriteTimeout exception. If a write outright fails on too many replicas, the response to the client depends on the cause of the failure. For more information, see Errors and exception handling in Cassandra drivers.

Level Description Usage

Level	Description	Usage
`ALL`	A write must be written to the commit log and memtable on all replica nodes in the cluster for that partition.	This write consistency level provides the highest consistency, the highest latency, and the lowest availability of any level.
`EACH_QUORUM`	A write must be written to the commit log and memtable on a quorum of replica nodes in each region (datacenter) where the database is deployed.	Use in in multi-datacenter clusters to strictly maintain consistency at the same level in each datacenter. Writes fail if any datacenter fails to achieve a quorum.
`QUORUM`	A write must be written to the commit log and memtable on a quorum of replica nodes across all datacenters.	Use in single or multiple datacenter clusters to maintain strong consistency across the cluster. Use if you can tolerate some level of failure. For linearizable consistency, use `SERIAL`
`LOCAL_QUORUM`	Avoids latency of inter-datacenter communication.	Use to maintain consistency within a single datacenter in multi-datacenter cluster. For linearizable consistency, use `LOCAL_SERIAL`
`ONE`	Not supported by Astra.	Not supported by Astra.
`TWO`	A write must be written to the commit log and memtable of at least two replica nodes.	Similar to `ONE`.
`THREE`	A write must be written to the commit log and memtable of at least three replica nodes.	Similar to `TWO`.
`LOCAL_ONE`	Not supported by Astra.	Not supported by Astra.
`ANY`	Not supported by Astra.	Not supported by Astra.
`SERIAL`	Achieves linearizable consistency by preventing unconditional updates.	Equivalent to `QUORUM` but only for use with lightweight transactions (LWTs). If requested for a non-LWT operation, it is ignored.
`LOCAL_SERIAL`	Same as `SERIAL` but confined to a single datacenter. Linearizable consistency is implemented within the local datacenter only.	Equivalent to `LOCAL_QUORUM` but only for use with LWTs.

ALL

A write must be written to the commit log and memtable on all replica nodes in the cluster for that partition.

This write consistency level provides the highest consistency, the highest latency, and the lowest availability of any level.

EACH_QUORUM

A write must be written to the commit log and memtable on a quorum of replica nodes in each region (datacenter) where the database is deployed.

Use in in multi-datacenter clusters to strictly maintain consistency at the same level in each datacenter. Writes fail if any datacenter fails to achieve a quorum.

QUORUM

A write must be written to the commit log and memtable on a quorum of replica nodes across all datacenters.

Use in single or multiple datacenter clusters to maintain strong consistency across the cluster. Use if you can tolerate some level of failure.

For linearizable consistency, use SERIAL

LOCAL_QUORUM

Avoids latency of inter-datacenter communication.

Use to maintain consistency within a single datacenter in multi-datacenter cluster.

For linearizable consistency, use LOCAL_SERIAL

ONE

Not supported by Astra.

TWO

A write must be written to the commit log and memtable of at least two replica nodes.

Similar to ONE.

THREE

A write must be written to the commit log and memtable of at least three replica nodes.

Similar to TWO.

LOCAL_ONE

Not supported by Astra.

ANY

Not supported by Astra.

SERIAL

Achieves linearizable consistency by preventing unconditional updates.

Equivalent to QUORUM but only for use with lightweight transactions (LWTs). If requested for a non-LWT operation, it is ignored.

LOCAL_SERIAL

Same as SERIAL but confined to a single datacenter. Linearizable consistency is implemented within the local datacenter only.

Equivalent to LOCAL_QUORUM but only for use with LWTs.

Read consistency levels

For read operations, the read consistency level specifies how many replicas must respond to a read request before returning data to the client application.

To complete a read request, the database must combine results from the table’s memtable and one or more SSTables. If the required partition data is found in multiple locations, the data is merged from the different sources to provide a complete view of the partition. Finding the data for a read request is a multi-stage process known as the read path.

Level Description Usage

Level	Description	Usage
`ALL`	Queries return the most recent data from all replica nodes in the cluster. All replica nodes must respond. The read operation fails if any replica does not respond.	This read consistency level provides the highest consistency, the highest latency, and the lowest availability of any level.
`EACH_QUORUM`	Queries return the most recent data from a quorum of replica nodes in each region (datacenter) where the database is deployed.	Use in multiple datacenter clusters to ensure data consistency at the same level in each datacenter. Queries fail if any datacenter fails to achieve a quorum.
`QUORUM`	Queries return the most recent data from a quorum of replica nodes across all datacenters.	Ensures strong consistency across the cluster if the replication factor is high enough to tolerate down nodes or timed-out cross-datacenter communication. Cross-datacenter communication can incur extra latency.
`LOCAL_QUORUM`	Queries returns the most recent data from a quorum of replicas in the current datacenter. Avoids latency of cross-datacenter communication.	Use to maintain consistency within the single datacenter in multiple-datacenter clusters with a rack-aware replica placement strategy, such as NetworkTopologyStrategy, and a properly configured snitch.
`LOCAL_ONE`	Queries return data from the closest replica node in the local datacenter.	Achieves a consistency level of `ONE` without cross-datacenter traffic. This is valuable for applications backed by multiple-datacenter clusters that require the lowest possible read latency. For security and compliance reasons, restricted or offline (airgapped) datacenters should always use `LOCAL_ONE`. If a local node goes down, `LOCAL_ONE` prevents the cluster from rerouting to nodes in other datacenters that might not be approved to handle the request. At the client level, you can implement logic to retry requests against specific alternate datacenters if this is a valid approach for your application.
`SERIAL`	Similar to `QUORUM` but for lightweight transactions. Reads at `SERIAL` allow reading the current (and possibly uncommitted) state of data without proposing a new addition or update. If a read at `SERIAL` finds an uncommitted transaction in progress, then the database performs a read repair to commit the write as part of the read.	Use to read the latest value of a column after a client has invoked an LWT to write to the column. Reads at `SERIAL` check the in-flight LWT for updates and, if found, returns the latest data.
`LOCAL_SERIAL`	Same as `SERIAL`, but confined to the local datacenter.	Equivalent to `LOCAL_QUORUM` but only for use with LWTs.
`ONE`	Queries return data from the closest replica.	Provides the highest availability of all the levels if you can tolerate a comparatively high probability of stale data being read. The replica contacted for the read might not have the most recent writes.
`TWO`	Queries return the most recent data from two of the closest replicas. Two replica nodes must respond.	Assuming the replication factor is greater than 3, provides high availability if you can tolerate a comparatively high probability of stale data being read. The replicas contacted for reads might not have the most recent writes. If the replication factor is 3, this is equivalent to `QUORUM`.
`THREE`	Queries return the most recent data from three of the closest replicas. Three replica nodes must respond.	Assuming the replication factor is greater than 3, this level provides high availability if you can tolerate a comparatively high probability of stale data being read. The replicas contacted for reads might not have the most recent writes. If the replication factor is 3, this is equivalent to `ALL`.

ALL

Queries return the most recent data from all replica nodes in the cluster. All replica nodes must respond. The read operation fails if any replica does not respond.

This read consistency level provides the highest consistency, the highest latency, and the lowest availability of any level.

EACH_QUORUM

Queries return the most recent data from a quorum of replica nodes in each region (datacenter) where the database is deployed.

Use in multiple datacenter clusters to ensure data consistency at the same level in each datacenter. Queries fail if any datacenter fails to achieve a quorum.

QUORUM

Queries return the most recent data from a quorum of replica nodes across all datacenters.

Ensures strong consistency across the cluster if the replication factor is high enough to tolerate down nodes or timed-out cross-datacenter communication. Cross-datacenter communication can incur extra latency.

LOCAL_QUORUM

Queries returns the most recent data from a quorum of replicas in the current datacenter. Avoids latency of cross-datacenter communication.

Use to maintain consistency within the single datacenter in multiple-datacenter clusters with a rack-aware replica placement strategy, such as NetworkTopologyStrategy, and a properly configured snitch.

LOCAL_ONE

Queries return data from the closest replica node in the local datacenter.

Achieves a consistency level of ONE without cross-datacenter traffic. This is valuable for applications backed by multiple-datacenter clusters that require the lowest possible read latency.

For security and compliance reasons, restricted or offline (airgapped) datacenters should always use LOCAL_ONE. If a local node goes down, LOCAL_ONE prevents the cluster from rerouting to nodes in other datacenters that might not be approved to handle the request. At the client level, you can implement logic to retry requests against specific alternate datacenters if this is a valid approach for your application.

SERIAL

Similar to QUORUM but for lightweight transactions.

Reads at SERIAL allow reading the current (and possibly uncommitted) state of data without proposing a new addition or update. If a read at SERIAL finds an uncommitted transaction in progress, then the database performs a read repair to commit the write as part of the read.

Use to read the latest value of a column after a client has invoked an LWT to write to the column. Reads at SERIAL check the in-flight LWT for updates and, if found, returns the latest data.

LOCAL_SERIAL

Same as SERIAL, but confined to the local datacenter.

Equivalent to LOCAL_QUORUM but only for use with LWTs.

ONE

Queries return data from the closest replica.

Provides the highest availability of all the levels if you can tolerate a comparatively high probability of stale data being read. The replica contacted for the read might not have the most recent writes.

TWO

Queries return the most recent data from two of the closest replicas. Two replica nodes must respond.

Assuming the replication factor is greater than 3, provides high availability if you can tolerate a comparatively high probability of stale data being read. The replicas contacted for reads might not have the most recent writes.

If the replication factor is 3, this is equivalent to QUORUM.

THREE

Queries return the most recent data from three of the closest replicas. Three replica nodes must respond.

Assuming the replication factor is greater than 3, this level provides high availability if you can tolerate a comparatively high probability of stale data being read. The replicas contacted for reads might not have the most recent writes.

If the replication factor is 3, this is equivalent to ALL.

How `QUORUM` is calculated

The QUORUM level writes to the number of nodes (replicas) that make up a quorum.

For Astra, a quorum is 2 replicas per region:

Single-region database: 2 replicas.
Multi-region database at QUORUM: 2 replicas multiplied by the number of regions. For example, a database deployed to 4 regions requires 8 replicas for QUORUM (4 x 2 = 8). QUORUM requires responses from a quorum of the total replicas across all regions; any replica can respond to satisfy the quorum.
Multi-region database at EACH_QUORUM: 2 replicas from each region. This is stricter than QUORUM because it requires separate regional quorums.
Multi-region database at LOCAL_QUORUM: 2 replicas from the targeted region.

Consistency level performance

Before changing the consistency level in production, use the CQL shell TRACING command to measure request performance at different consistency levels.

Consistency levels

Write consistency levels

Read consistency levels

How `QUORUM` is calculated

Consistency level performance

See also

Was this helpful?

Give Feedback

Consistency levels

Write consistency levels

Read consistency levels

How QUORUM is calculated

Consistency level performance

See also

Was this helpful?

How `QUORUM` is calculated