Astra DB replication and distribution

By default, each Astra DB Serverless database is deployed to one region, also known as the primary region. You select this region when you create the database.

You can deploy databases to additional regions (multi-region databases). When you deploy a database to an additional region, data is streamed from the primary region.

Triple replication

Within each deployed region, Astra DB replicates data across three availability zones. This promotes uptime and ensures data integrity.

For each keyspace, the replication factor is 3 and the replication strategy is NetworkTopologyStrategy. These settings are configured by DataStax as part of the Astra managed service offering. You cannot change the replication strategy, replication factor, or independently manage, restrict, or modify replicas.

In Apache Cassandra-based databases, data is organized into tables that use primary keys to identify unique records. When the replication factor is greater than 1, data is stored on multiple nodes that are known as replicas. If a replica is busy or fails, read/write requests can be forwarded to other replicas that store the same data.

In Astra, the total amount of data managed by the cluster is represented as a ring. Astra divides the ring into a number of token ranges equal to the number of nodes. Table data is partitioned across the nodes based on row keys that correspond to token ranges. When reading or writing a row, Astra uses the row key to determine the token and locate the node responsible for that token range.

Eventual consistency

Astra DB follows an eventual consistency model: when you write to an Astra DB database, the data is eventually replicated across all of the database’s replicas.

When you write to a multi-region database, the data is eventually replicated across all regions where the database is deployed, regardless of the region that received the original write request.

The time required to replicate data across all regions and availability zones depends on the number of regions, workload volume, and network resources. Generally, data replication takes minutes, but it can take hours or days if there are failures or outages.

Repair cycles

If a write request succeeds in one region and fails in another, Astra DB attempts to repair the inconsistency. Generally, repair cycles range from a few minutes to a few hours, but they can take days if a network disruption occurs between regions. Network disruptions can limit or prevent the following operations:

  • Schema changes

  • Table truncation

  • Lightweight transactions (LWTs), also known as compare-and-set (CAS) or read-before-write operations

  • Data repair

Consistency levels

Consistency levels determine the number of replicas that must acknowledge a read or write operation before it’s considered successful. For information about supported and default consistency levels, see Consistency levels.

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