Astra DB Serverless database limits
Astra DB Serverless is a fully managed serverless database-as-a-service (DBaaS) that is 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.
Monitor 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.
Compaction limits
-
Only the UnifiedCompactionStrategy (UCS) is allowed. This strategy unifies and improves upon SizeTieredCompactionStrategy (STCS) and LeveledCompactionStrategy (LCS). It also supports time series data. 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 Astra DB Serverless database can have up to 200 tables.
A warning is issued when the database exceeds 100 tables.
For databases in PCU groups, a single PCU group cannot support more than 5000 tables across all databases in the group, on average.
-
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, 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 value in a column cannot exceed 10 MB of data.
-
Data API limits apply when inserting data into tables with the Data API.
-
A table in a Astra DB Serverless database can have no more than 75 columns.
If your data model suggests that you need more columns per table, then you must redistribute data across tables, or use frozen User-Defined Types (UDTs) or collection columns (maps, lists, and sets) to combine related data into fewer 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.
Collection limits
The following limits apply to collections:
-
Astra DB Serverless 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, 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 collection cannot have more than 64 fields, as extracted from all documents inserted into the collection.
-
Data API limits apply when inserting documents into collections, either through the Astra Portal or the Data API.
Index limits
|
When designing your data model, index limits are a critical factor for query performance and scalability. |
- Collection indexes
-
There is a limit to the number of Storage-Attached Indexing (SAI) indexes you can have in Astra DB Serverless databases:
-
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).
-
Each collection can have up to 10 indexes. Collections automatically create indexes for all fields (up to a maximum of 10), unless you apply selective indexing when you create the collection. For more information, see Indexes in collections (HTTP).
-
- Table indexes
-
These limits apply to tables in Astra DB Serverless databases:
-
A database created before June 24, 2024 can have up to 50 indexes total.
-
A database created after June 24, 2024 can have up to 100 indexes total.
-
A table can have up to 10 indexes.
-
For databases with collections and tables, the total number of indexes is the sum of the table indexes and collection indexes.
-
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, consider Provisioned Capacity Units for Astra DB Serverless.
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.
Data API limits
For information about Data API limits, see Data API limits.
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.
-
Inactive Astra DB Serverless databases are automatically hibernated and scheduled for deletion.
-
Cannot export metrics for Astra DB Serverless databases.
-
Cannot use premium features, such as private endpoints or multi-region databases.
To remove these limits, upgrade your plan.
cassandra.yaml guardrails
The cassandra.yaml file is not configurable for Astra DB Serverless databases.
The following general guardrails are set in the cassandra.yaml file, which inform some of the limits described elsewhere on this page, such as index limits.
Some deployment types enforce additional or different guardrails. For example, small, medium, and cache optimized PCU types have unique guardrails.
# 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 # Or 50 for databases created before June 24, 2024PCU guardrails and limits
The following guardrails and limits apply to PCU types.
In the context of these guardrails and limits, table refers to tables, vector-enabled collections, and non-vector collections.
Collection refers to the CQL collection types: map, list, and set.
| Guardrail | General PCU limit | Cache optimized PCU limit | Medium PCU limit | Small PCU limit | Outcome when surpassed |
|---|---|---|---|---|---|
Maximum number of tables across all databases in the PCU group |
5000 |
5000 |
5000 |
5000 |
Cannot add more databases to the group |
Maximum number of databases in the PCU group |
500 |
500 |
500 |
500 |
Cannot add more databases to the group |
Maximum bloom filter memory usage across all databases in the PCU group |
7,000 MB |
10,000 MB |
3,000 MB |
1,500 MB |
Cannot add more databases to the group |
Maximum number of tables for a single database within a PCU group |
200 |
200 |
100 |
50 |
Cannot add more tables to the overloaded database |
Maximum number of indexes for a single database within a PCU group |
50 |
50 |
25 |
12 |
Cannot create more indexes in the overloaded database |
Maximum SAI indexes per table |
10 |
10 |
7 |
5 |
Cannot create more SAI indexes on the overloaded table. |
|
64 KB |
64 KB |
32 KB |
16 KB |
Non-blocking warning issued if a |
Maximum |
640 KB |
640 KB |
320 KB |
160 KB |
Error issued if a |
Maximum size for a single column value |
10240 KB |
10240 KB |
5120 KB |
2560 KB |
The write operation is rejected if the column value exceeds the threshold. |
Serialized collection size warning (bytes required for the database to store and navigate the collection internally) |
5120 KB |
5120 KB |
2560 KB |
1280 KB |
Non-blocking warning issued if a CQL statement has a collection exceeding the threshold. Typically exhausted more quickly for unfrozen collections due to each item being stored and navigated separately. |
Items in collection warning |
20 |
20 |
10 |
5 |
Non-blocking warning issued if a CQL statement has a collection exceeding the threshold. |
Tombstones read warning |
1,000 |
1,000 |
500 |
250 |
Non-blocking warning issued if a CQL statement reads many tombstones. |
Maximum tombstones read |
10,000 |
10,000 |
5,000 |
2,500 |
Error issued if a CQL statement reads too many tombstones. The operation fails. |
Rows skipped by |
10,000 |
10,000 |
5,000 |
2,500 |
Non-blocking warning issued if a CQL statement has many skipped rows. |
Maximum rows skipped by |
20,000 |
20,000 |
10,000 |
5,000 |
Error issued if a CQL statement has too many skipped rows. The operation fails. |
Large partition warning |
100 MB |
100 MB |
50 MB |
25 MB |
Internal log message recorded if a large partition compaction occurs. IBM Support might use these logs to help you troubleshoot underperforming databases. |
Maximum columns per table |
75 |
75 |
38 |
19 |
|
Maximum fields per UDT |
60 |
60 |
30 |
15 |
|
Maximum vector dimensions for |
8,192 |
8,192 |
4,096 |
2,048 |
|
