Plan your PCU groups in Astra DB

When you create Provisioned Capacity Unit (PCU) groups, your choices can have long-term billing implications and immediate performance impacts on your databases.

Take time to plan your PCU groups to ensure appropriate provisioning and help manage costs.

How to use this planning guide

This guide assumes that you understand the basic PCU terminology and concepts that are explained in Provisioned Capacity Units for Astra DB Serverless. Familiarity with these concepts is essential to effective PCU group planning.

This guide demonstrates several possible PCU group configurations, in addition to general PCU group planning information. These configurations are for example purposes only. There are many factors that are beyond the scope of this guide, and it is impossible to describe every scenario. Consider the recommendations and examples provided here, and then make adjustments for the particular needs of your workloads.

Determine how many PCU groups you need

By definition, PCUs are finite resources, and PCU groups can’t support an infinite number of databases. Unless you have only one database, you will most likely need multiple PCU groups.

Use the following guidelines to create an initial plan for your PCU groups, including how many PCU groups you need and which databases to put in each group. After you create a few PCU groups, monitor them and adjust your plan accordingly. You might decide to put more databases in each group or separate more active databases from other databases. For a personalized calculation and cost estimation, contact your DataStax account representative.

PCU groups are confined to the Astra DB organization where you create them. If you have multiple organizations, you need to create separate PCU groups for the databases in each organization.
PCU groups are region-specific. For example, databases in AWS us-east-1 can’t share a PCU group with databases in Google Cloud us-east1.

You must create separate PCU groups for each region where your databases are deployed, including multi-region databases. For example, if you have a multi-region database deployed to us-east-1, ap-south-1, and eu-west-1, then you need three total PCU groups, one for each region.
PCU groups can include either Serverless (Vector) databases or Serverless (Non-Vector) databases. If you use both database deployment types, then you need separate PCU groups for the two types.
All databases in a PCU group share the group’s allocated capacity. If you put multiple databases in the same group, make sure the group’s allocated capacity can support those databases.

For example, if traffic increases for one database in a group, that database can consume a higher share of resources during the spike, potentially causing performance issues for other databases in the same group.
To balance resource consumption, you can isolate resource intensive databases to their own PCU groups, or you can selectively group certain databases together. Even small databases can be resource intensive.

Here are some tips for identifying resource intensive databases:
- The overall database size is more than half of the cache size.
- The database has unpredictable peaks where the load increases by a factor of two or more in a matter of minutes and then subsides.
- The database must support complex workloads like vector search or LWT.
Add databases to a group gradually, rather than adding them all at once.

This allows you to monitor performance after each addition to ensure that the databases don’t outpace the group’s capacity, and you can quickly identify which database to remove if performance degrades.

Determine capacity per group

This section provides generic guidance for allocating capacity to your PCU groups. For more a formal calculation and cost estimation, contact your DataStax account representative.

Capacity is billed at either the RCU or HCU rate, and this is determined by the amount of reserved, minimum, and maximum capacity that you assign to a group. For more information, see Capacity allocation.
Reserved capacity is typically more cost effective for long-term, continuous availability.

Although reserved capacity requires a long-term commitment, it is billed at the RCU rate that can be more cost effective when compared to an equal number of constantly-provisioned HCUs.

Any workload that requires long-term, continuous availability is an ideal candidate for at least one reserved PCU.
To determine minimum and maximum capacity, consider average traffic, peak traffic, and your tolerance for autoscaling.

Minimum capacity represents a fixed amount of capacity that you want continuously available for your databases, and maximum capacity represents an additional margin of capacity for unexpected spikes in demand.

The maximum capacity is the total possible capacity. You can use the maximum to handle all above-average traffic, or you can use the maximum as an emergency buffer for extreme spikes.

For example, if you set the minimum capacity above your average capacity, then your databases will have a cushion available for spikes before autoscaling into the maximum capacity. For more information and examples for handling variable traffic, see PCU group configuration guides.
Serverless (Vector) databases can have only one PCU per PCU group. If you require additional capacity for Serverless (Vector) databases, contact your DataStax account representative or DataStax Support.
A single PCU group can’t exceed 10 units total.

This amount of capacity is far beyond what is required for all but the most resource-intensive workloads with massive working datasets.

If you have a PCU group that requires more than 10 units, and the group has multiple databases, consider separating some of the databases into other PCU groups to reduce competition for resources among large or highly active databases.

If you need more than 10 units for a single database or splitting up your databases isn’t feasible, contact your DataStax account representative or DataStax Support.
Consider cache optimization for workloads with large working datasets.

Cache storage is cumulative across all units in a PCU group, and cache optimized PCUs have more cache storage than standard PCUs. Cache optimized PCUs can be a more economical choice than standard PCUs because your workloads might require fewer cache optimized units than standard units. For more information, see Cache optimization.

Avoid unintentional over- and under-commitment

When you create or edit PCU groups, use these strategies to avoid unintentionally provisioning too much or too little capacity:

If you know you want at least one reserved PCU, start with a reserved capacity of 1, a minimum capacity of 1, and a maximum capacity of 2. Then, monitor database performance and increase the minimum and maximum if you are missing your performance targets.

By increasing the minimum and maximum, you can test the increased capacity without increasing your RCU commitment. When you are ready, you can increase the reserved capacity to permanently increase your RCU commitment.

Alternatively, your use case might dictate that you keep the surplus minimum capacity, which is billed at the HCU rate. For more information and examples, see PCU group configuration guides.
Use flexible capacity workloads to test different PCU group configurations before making an RCU commitment. If you decide to consolidate PCU groups after testing, you can park or delete the flexible capacity PCU groups to minimize costs. For an example, see Test capacity before moving production workloads.
After you create a PCU group or change a PCU group’s capacity, continue to monitor usage and adjust the group’s configuration based on actual usage and changing needs. For example, you might move growing databases into separate PCU groups or increase capacity to support increased demand.

Test capacity before moving production workloads

Generally, there should be little or no downtime when moving databases from on-demand to PCU or between PCU groups.

However, as with any potential disruption to production and mission-critical workloads, consider moving your most sensitive databases during maintenance windows or other low-traffic hours.

You can use test environments to ensure your production PCU groups have sufficient capacity before cutting over your production workloads.

Create a separate database for testing, if you don’t already have a separate development or test database.
Create a flexible capacity PCU group, and add your test database to the group.

Flexible capacity PCU groups are billed at the HCU rate, which is more cost effective for testing because you can change the capacity without making a long-term commitment. When you are done with testing, you can park or delete the group to minimize costs.
Set the test group’s minimum capacity to your expected production database capacity.

If you aren’t sure, start with a minimum capacity of one, and then increase the minimum capacity based on the results of your tests.
Set the test group’s maximum capacity, cache optimization, and provision type according to your expected production PCU group configuration.

Initially, consider setting the maximum capacity equal to the minimum capacity so your tests aren’t influenced by autoscaling.

If you aren’t sure whether you need cache optimization, see Cache optimization. You can also create two flexible capacity PCU groups, with and without cache optimization. Then, you can test each configuration separately by moving your test database from one to the other. Make sure that you park the groups when you aren’t using them.
Run performance tests against the test database to see if the allocated capacity and other settings support your performance targets.
Continue to adjust the minimum capacity and rerun your tests until you determine the ideal capacity.

If you started with a minimum capacity of two or more, you might test a lower capacity to ensure that you aren’t unnecessarily over-provisioning the group.
Configure your production database’s PCU group to align with the test database’s PCU group configuration. Set the reserved capacity according to the minimum capacity that you identified in your testing.
To manage costs for the test group after you are done with testing, you can park the group or reduce the minimum capacity to one.

PCU group configuration guides

These configuration guides demonstrate general PCU group configurations based on DataStax recommendations. However, there are many factors that are beyond the scope of these guides, and it is impossible to describe every scenario. Consider the recommendations and examples provided here, and then make adjustments for the particular needs of your workloads.

These examples build on the information provided in Determine how many PCU groups you need and Determine capacity per group.

Workloads that require continuous availability

Use this configuration as a basis for databases that are long-lived, require continuous availability, and never need to scale to zero. This configuration accounts for both predictable continuous traffic and unpredictable traffic spikes.

Serverless (Non-Vector) databases
Serverless (Vector) databases

Workload type: Committed capacity
Reserved: One or more, depending on capacity requirements, such as the number of databases in the group and the volume of traffic. You can start with a reserved capacity of one, monitor usage, and then increase the reserved capacity if needed.
Minimum: Equal to the reserved capacity.

For more information about allocating capacity for cyclical traffic spikes, see Cyclical or seasonal traffic spikes.
Maximum: Greater than the minimum capacity to allow autoscaling of additional capacity. Generally, the maximum should represent the total possible capacity you need based on your assessment of maximum volatility.

If budget is a concern, you can set the maximum equal to the minimum to disable autoscaling. However, without autoscaling, if your workloads exceed the minimum, performance degradation is likely.
Provision type: Dependent on your unique requirements.
Cache optimized: Dependent on your unique requirements, like the size of your working dataset.

Workload type: Committed capacity
Reserved, Minimum, and Maximum: For Serverless (Vector) databases, the reserved, minimum, and maximum capacity must be exactly one and cannot exceed one.

Autoscaling must be disabled by setting the maximum equal to the minimum.

Serverless (Vector) databases can have only one PCU per PCU group. If you require additional capacity for Serverless (Vector) databases, contact your DataStax account representative or DataStax Support.
Provision type: Dependent on your unique requirements.
Cache optimized: DataStax strongly recommends cache optimization for Serverless (Vector) databases.

For multi-region databases, follow the specific guidance provided in Multi-region databases.

Workloads that can scale to zero

Use this configuration as a basis for databases that don’t need continuous availability, such as test environments that are active only during testing.

Serverless (Non-Vector) databases
Serverless (Vector) databases

Workload type: Flexible capacity.

Flexible capacity workloads don’t require a long-term commitment to reserved capacity. They are always billed at the HCU rate, but you can park or delete these PCU groups when you don’t need them.

However, for databases that need long-term continuous availability, the RCU rate (reserved capacity) typically provides cost savings over the HCU rate. This threshold is around 450 hours per month for multiple months. If you expect this PCU group to exceed this threshold, consider the recommended configuration for committed capacity workloads instead of the flexible capacity model.
Reserved: Zero
Minimum: One or more, depending on capacity requirements, such as the number of databases in the group and the volume of traffic. You can start with a minimum capacity of one, monitor usage, and then increase the capacity if needed.
Maximum: Greater than the minimum, if you want to allow autoscaling of additional capacity as needed. Otherwise, you can set the maximum equal to the minimum to disable autoscaling.
Provision type: Dependent on your unique requirements.
Cache optimized: Dependent on your unique requirements, like the size of your working dataset.

Workload type: Flexible capacity.

Flexible capacity workloads don’t require a long-term commitment to reserved capacity. They are always billed at the HCU rate, but you can park or delete these PCU groups when you don’t need them.

However, for databases that need long-term continuous availability, the RCU rate (reserved capacity) typically provides cost savings over the HCU rate. This threshold is around 450 hours per month for multiple months. If you expect this PCU group to exceed this threshold, consider the recommended configuration for committed capacity workloads instead of the flexible capacity model.
Reserved: Zero
Minimum and Maximum: For Serverless (Vector) databases, the minimum and maximum capacity must be exactly one and cannot exceed one.

Autoscaling must be disabled by setting the maximum equal to the minimum.

Serverless (Vector) databases can have only one PCU per PCU group. If you require additional capacity for Serverless (Vector) databases, contact your DataStax account representative or DataStax Support.
Provision type: Dependent on your unique requirements.
Cache optimized: DataStax strongly recommends cache optimization for Serverless (Vector) databases.

Multi-region databases

Use this configuration as a basis for databases that are deployed to multiple regions. This configuration account for both predictable, continuous traffic and unpredictable traffic spikes.

Serverless (Non-Vector) databases
Serverless (Vector) databases

Cloud provider and Region: You must create one PCU group per deployed region.

For example, if a database is deployed to us-east-1 and eu-west-1, you need a PCU group for us-east-1 and a PCU group for eu-west-1, and then add the same database to both groups.
Workload type: Committed capacity
Reserved: One or more, depending on capacity requirements, such as the number of databases in the group and the volume of traffic. You can start with a reserved capacity of one, monitor usage, and then increase the reserved capacity if needed.

For a multi-region database, each region’s PCU group can have a different amount of capacity depending on the regional traffic volume and latency tolerance.
Minimum: Equal to the reserved capacity.

If you temporarily need additional capacity for sustained cyclical traffic spikes, see Cyclical or seasonal traffic spikes.
Maximum: Greater than the minimum capacity to allow autoscaling of additional capacity. Generally, the maximum should represent the total possible capacity you need based on your assessment of maximum volatility.

If budget is a concern, you can set the maximum equal to the minimum to disable autoscaling. However, without autoscaling, if your workloads exceed the minimum, performance degradation is likely.
Provision type: If a multi-region database requires dedicated tenancy in any region, then you must enable dedicated tenancy in all of the related PCU groups.
Cache optimized: If a multi-region database requires cache optimization in any region, then you must enable cache optimization in all of the related PCU groups.

Cloud provider, Region, and Scoped databases: You must create one PCU group per deployed region.

For example, if a database is deployed to us-east-1 and eu-west-1, you need a PCU group for us-east-1 and a PCU group for eu-west-1, and then add the same database to both groups.
Workload type: Committed capacity
Reserved, Minimum, and Maximum: For Serverless (Vector) databases, the reserved, minimum, and maximum capacity must be exactly one and cannot exceed one.

Autoscaling must be disabled by setting the maximum equal to the minimum.

Serverless (Vector) databases can have only one PCU per PCU group. If you require additional capacity for Serverless (Vector) databases, contact your DataStax account representative or DataStax Support.
Provision type: If a multi-region database requires dedicated tenancy in any region, then you must enable dedicated tenancy in all of the related PCU groups.
Cache optimized: DataStax strongly recommends cache optimization for Serverless (Vector) databases.

Cyclical or seasonal traffic spikes

Use this configuration to edit an existing committed capacity PCU group to temporarily increase the group’s capacity without increasing your RCU commitment. For example, use this configuration if you need additional capacity for a few days or weeks to support a projected temporary increase in demand.

This guidance is only for committed capacity workloads for Serverless (Non-Vector) databases.

For flexible capacity workloads, you can adjust the minimum and maximum capacity at any time.

For Serverless (Vector) databases, the capacity must not exceed one unit. If you require additional capacity for Serverless (Vector) databases, contact your DataStax account representative or DataStax Support.

To accommodate traffic spikes, you can choose to increase the minimum, maximum, or both. This choice depends on when you prefer the additional capacity to be available to your databases:

If you want to prepare additional capacity in advance of a high-traffic event, increase the minimum.
If you want to increase the margin for autoscaling, increase the maximum.
If you want to do both, increase the minimum and maximum.

Prepare additional capacity in advance (minimum capacity)
Increase autoscaling range (maximum capacity)

To temporarily increase a PCU group’s continuously-available capacity, set the minimum capacity to be greater than the reserved capacity.

For example, if the reserved and minimum are one, and you want to provision two additional units for a short time, then set the minimum to three. This increases the total amount of continuously available PCUs without increasing the RCU commitment.

If the maximum capacity is greater than the minimum, increment the maximum by the same amount or more to maintain your autoscaling buffer. For example, if you increased the minimum by two, increase the maximum by two as well.

Upon saving the changes, Astra DB immediately provisions additional PCUs to meet the new minimum. These additional PCUs are billed for continuous usage at the HCU rate until you decrease the minimum capacity or increase the reserved capacity to be equal to the minimum.

To temporarily increase the autoscaling range, increase the maximum capacity to your projected peak demand to allow autoscaling for increased demand.

You can increase the maximum alone or in addition to increasing the minimum capacity.

However, if you only increase the maximum, then your databases might experience temporary performance impacts if demand increases too fast for the autoscaler. If this is a concern, consider increasing both the minimum and the maximum so you have some extra capacity available by default before your databases reach the autoscaling threshold.

For multi-region Serverless (Non-Vector) databases, make sure you adjust the capacity in all relevant PCU groups.

When you no longer need the additional capacity, edit the group again to reset the minimum and maximum to their original levels.

If you decide that you want to keep the additional capacity permanently, DataStax recommends increasing the reserved capacity because the RCU rate typically provides cost savings over long-term continuous usage at the HCU rate.