Astra Managed Clusters database limits
Astra Managed Clusters databases are powered by Apache Cassandra®, an open-source NoSQL distributed database. To ensure high availability and optimum performance, Astra Managed Clusters databases have guardrails on underlying Cassandra functionality.
Monitoring databases
You can view health metrics in the Astra Portal.
By design, Astra DB alleviates the complexities of database management so you can focus on developing applications.
Astra DB isn’t compatible with some Cassandra operational tools, such as nodetool and cfstats.
Astra DB doesn’t support accessing databases with Java Management Extensions (JMX) tools, such as JConsole.
Security and access control
Astra DB provides secure, cloud-based databases without dramatically changing the way you currently access your internal databases:
-
User management doesn’t require Cassandra superusers or global keyspace administration. For information about user management and role-based access control (RBAC) in Astra, see Manage roles and permissions.
-
Endpoints are secured using mutual authentication, either with mutual-TLS or secure tokens issued to the client.
-
TLS provides a secure transport layer you can trust, ensuring that in-flight data is protected.
-
Data at rest is protected by encrypted volumes.
For more information, see Download and use a Secure Connect Bundle (SCB) with an Astra Managed Clusters database, Manage application tokens, and other security-related topics such as Use private endpoints.
Replicas and consistency
By default, each Astra Managed Clusters 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 queried and replicated 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.
- Eventual consistency
-
Astra DB follows an eventual consistency model, and you cannot independently manage, restrict, or modify replicas.
When you write to an Astra DB database, it 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.
- Consistency levels
-
Consistency levels determine the number of replicas that must acknowledge a read or write operation before it’s considered successful.
Cassandra Query Language (CQL) for Astra DB (accessible through the CQL shell and Cassandra drivers) supports all read consistency levels, and it supports all write consistency levels except
ONE,ANY, andLOCAL_ONE.LOCAL_QUORUMis 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, orALL. However, these consistency levels have higher latency thanLOCAL_QUORUMbecause they require acknowledgement from replicas in all regions.ALLhas the highest latency because it requires acknowledgement from all replicas in all regions.
For more information, see Replication and consistency in Cassandra-based databases.
Compaction limits
-
Only the
UnifiedCompactionStrategycompaction strategy is allowed. This strategy combines ideas fromSizeTieredCompactionStrategy,LeveledCompactionStrategy, andTimeWindowCompactionStrategy, along with token range sharding. This all-inclusive compaction strategy works well for Astra DB use cases. -
A warning is issued when reading or compacting a partition that exceeds 100MB.
Table limits
-
A database can have up to 200 tables.
A warning is issued when the database exceeds 100 tables.
-
For multi-region databases, the Astra Portal’s Data Loader accesses and manipulates tables and data from the primary region. If you need to manage your database from a secondary region, you must use CQL shell or a Cassandra driver to connect directly to that region. Generally, accessing secondary regions is for latency optimization when the primary region is geographically distant from the caller or when the primary region is experiencing an outage. However, because multi-region databases follow an eventual consistent model, changes to data in any region are eventually replicated to the database’s other regions.
-
A single column cannot have values larger than 5 MB.
-
All table properties are fixed except for expiring data with time-to-live.
-
A table can have no more than 50 columns.
-
You cannot
UPDATEorDELETEa list value by index because Astra DB doesn’t allow list operations that perform a read-before-write. Operations that are not by index work normally, includingUPDATE,DELETE, andINSERT.
Index limits
|
When designing your data model, index limits are a critical factor for query performance and scalability. |
-
A table can have no more than 10 indexes.
-
A database can have no more than 50 indexes total.
-
For Tier E Astra Managed Clusters databases, each table can have only one secondary index.
Rate limits
Astra Managed Clusters database workloads don’t have a rate limit.
CQL limits
For information about guardrails and limits for CQL commands, see Cassandra Query Language (CQL) for Astra DB.
Free plan limits
In addition to the limits described elsewhere on this page, organizations on the Free plan have the following additional limits:
-
No more than five Astra DB Serverless databases. Astra Managed Clusters databases aren’t available on the Free plan.
-
Inactive Astra DB Serverless databases are automatically hibernated and scheduled for deletion.
-
Cannot export metrics for Astra DB Serverless databases. Metrics export isn’t supported for Astra Managed Clusters databases.
-
Cannot use premium features, such as private endpoints or multi-region databases.
To remove these limits, upgrade your plan.
Cassandra configuration properties
The cassandra.yaml file is not configurable for Astra Managed Clusters databases.
This file is defined as follows:
# Read requests
page_size_failure_threshold_in_kb: 512
in_select_cartesian_product_failure_threshold: 25
partition_keys_in_select_failure_threshold: 20
tombstone_warn_threshold: 1000
tombstone_failure_threshold: 100000
# Write requests
batch_size_warn_threshold_in_kb: 5
batch_size_fail_threshold_in_kb: 50
unlogged_batch_across_partitions_warn_threshold: 10
user_timestamps_enabled: true
column_value_size_failure_threshold_in_kb: 5 * 1024L
read_before_write_list_operations_enabled: false
max_mutation_size_in_kb: 16384
# Schema
fields_per_udt_failure_threshold: 30
collection_size_warn_threshold_in_kb: 5 * 1024L
items_per_collection_warn_threshold: 20
columns_per_table_failure_threshold: 50
secondary_index_per_table_failure_threshold: 1 # 100 for Advanced Workloads.
tables_warn_threshold: 100
tables_failure_threshold: 200
# Node status
disk_usage_percentage_warn_threshold: 70
disk_usage_percentage_failure_threshold: 80
partition_size_warn_threshold_in_mb: 100
# Indexes failure threshold
sai_indexes_per_table_failure_threshold: 10
sai_indexes_total_failure_threshold: 100The limits defined in cassandra.yaml inform the limits described elsewhere on this page.
