Database limits

Astra DB Serverless is a fully managed serverless database-as-a-service (DBaaS), powered by Apache Cassandra®, an open-source NoSQL distributed database. To ensure high availability and optimum performance, Astra DB Serverless databases have guardrails on underlying Cassandra functionality.

Replicas

Astra DB Serverless 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 can’t 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

The Data API and clients always use the LOCAL_QUORUM consistency level for reads and writes.

With CQL and DataStax 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.

Tables

A Serverless (Vector) database can have up to 50 tables.
For multi-region databases, the Astra Portal’s Data Explorer accesses and manipulates keyspaces, collections, tables, and data from the primary region. If you need to manage your database from a secondary region, you must use the Data API or CQL shell. 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.

Collections

In the Astra Portal and the Data API, collections are containers for data within a database, similar to tables. This term has no relationship to collection data types (maps, lists, and sets) for columns in a table.

The following limits apply to collections, including read and write operations against data in collections:

Serverless (Vector) databases created after June 24, 2024 can have approximately 10 collections. Databases created before this date can have approximately 5 collections. The collection limit is based on the number of indexes.
For multi-region databases, the Astra Portal’s Data Explorer accesses and manipulates keyspaces, collections, tables, and data from the primary region. If you need to manage your database from a secondary region, you must use the Data API or CQL shell. 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.
Only the UnifiedCompactionStrategy compaction strategy is allowed. This strategy combines ideas from SizeTieredCompactionStrategy, LeveledCompactionStrategy, and TimeWindowCompactionStrategy, along with token range sharding. This all-inclusive compaction strategy works well for Astra DB Serverless use cases.
A warning is issued when reading or compacting a partition that exceeds 100MB.
You cannot UPDATE or DELETE a list value by index because Astra DB Serverless does not allow list operations that perform a read-before-write. Operations that are not by index work normally.

Fields

The following limits apply to Astra DB fields, which are the properties of documents stored in collections:

A collection can’t have more than 64 fields.
A document can’t have more than 10MB of data in a single field.

Indexes

There is a limit to the number of indexes you can have:

A database created before June 24, 2024 can have up to 50 indexes (approximately 5 collections).
A database created after June 24, 2024 can have up to 100 indexes (approximately 10 collections).
A single collection in a database can have up to 10 indexes.
This limit doesn’t apply to tables.

For more information, see Indexes in collections.

Rate limits

The default Astra DB Serverless rate limit is approximately 12,000 operations per second (ops/sec). Batches count as a single operation, regardless of the number of operations in a batch.

Astra DB Serverless workloads can be limited to 4,096 ops/sec for new or idle database when traffic suddenly increases suddenly. If you expect a sudden increase in traffic for an idle database, try to warm up your database before the workload increases. Make sure your database is active, and then send requests to your database to gradually increase the workload to the desired level over a period of time.

For production databases that require consistent capacity for traffic spikes, contact your account representative to learn more about provisioned capacity.

If you encounter rate limiting exceptions or errors, you might need to allow some time for the database to scale up before retrying your request. Alternatively, you can use programmatic strategies to balance and retry workloads, such as request batching, generic retry policies, and retry policies with backoff strategies. How you implement these strategies depends on your chosen connection method and use case.

Cassandra configuration properties

The cassandra.yaml file is not configurable for Astra DB Serverless databases. This file is defined as follows:

cassandra.yaml

# Read requests
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: 64
batch_size_fail_threshold_in_kb: 640
unlogged_batch_across_partitions_warn_threshold: 10
user_timestamps_enabled: true
column_value_size_failure_threshold_in_kb: 5 * 2048L
read_before_write_list_operations_enabled: false
max_mutation_size_in_kb: 16384
write_consistency_levels_disallowed: ANY, ONE, LOCAL_ONE

# Schema
fields_per_udt_failure_threshold: 60
collection_size_warn_threshold_in_kb:  5 * 1024L
items_per_collection_warn_threshold:  20
columns_per_table_failure_threshold: 75
tables_warn_threshold: 100
tables_failure_threshold: 200

# SAI indexes failure threshold
sai_indexes_per_table_failure_threshold: 10
sai_indexes_total_failure_threshold: 100   # 50 for databases created before June 24, 2024

The limits defined in cassandra.yaml inform the limits described elsewhere on this page.

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.
Can’t export metrics.
Can’t use premium features, such as custom domains and multi-region databases.

To increase or remove these limits, upgrade your plan.