Astra DB Classic database limits
Astra DB Classic is powered by Apache Cassandra®, an open-source NoSQL distributed database. To ensure high availability and optimum performance, Astra DB Classic databases have guardrails on underlying Cassandra functionality.
Monitoring databases
You can view and export health metrics from the Astra Portal.
By design, Astra DB Classic 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 a secure cloud-based database without dramatically changing the way you currently access your internal database:
-
User management doesn’t require CQL-based superusers or global keyspace administration. For information about user management and role-based access control (RBAC) in Astra DB, 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 Astra DB Classic, Use application tokens, and other security-related topics such as Use private endpoints.
Replicas
Astra DB Classic replicates data across three availability zones within each deployed region to promote uptime and ensure data integrity.
By default, each database is deployed to a single region, and you can deploy databases to additional regions.
Astra DB follows the eventual consistency model, and you cannot independently manage, restrict, or modify replicas. When you load data into an Astra DB database, it is eventually replicated across all of the database’s replicas, regardless of the original region where you loaded the data.
For multi-region databases, it can take time to replicate data across all regions. For more information, see Data consistency in multi-region databases.
Consistency levels
With CQL and drivers, you can use all read consistency levels and 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.
For more information about consistency levels, see the CQL documentation on CONSISTENCY and Data consistency in multi-region databases.
Reads and writes
-
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 Classic use cases. -
A warning is issued when reading or compacting a partition that exceeds 100MB.
-
You cannot
UPDATEorDELETEa list value by index because Astra DB Classic does not allow list operations that perform a read-before-write. Operations that are not by index work normally, includingUPDATE,DELETE, andINSERT.
Tables
-
A database can have no more than 200 tables. A warning is issued when the database exceeds 100 tables.
-
All table properties are fixed except for expiring data with time-to-live.
-
Classic databases can have only one secondary index per table.
-
Classic databases can have no more than two materialized views per table. A warning is issued if the materialized view creates large partitions.
Columns
-
A single column cannot have values larger than 5MB.
-
A table can have no more than 50 columns.
Indexes
-
A table can have no more than 10 indexes.
-
A database can have no more than 50 indexes total.
Rate limits
Astra DB workloads for Classic databases do not have a rate limit.
CQL limits
For information about guardrails and limits for CQL commands, see Cassandra Query Language (CQL) for Astra DB.
Free plans
In addition to the limits described elsewhere on this page, organizations on the Free plan have the following additional limits:
-
No more than five databases.
-
Inactive databases are automatically hibernated and scheduled for deletion. For more information, see Database statuses: Hibernated.
-
Cannot export metrics.
-
Cannot use premium features, such as private endpoints and multi-region databases.
To increase or remove these limits, upgrade your plan.
Cassandra configuration properties
The cassandra.yaml file is not configurable for Astra DB Classic 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.
