This page describes how resource usage, pricing, and cluster configurations work in CockroachDB Serverless.
All cluster activity, including SQL queries, bulk operations, and background jobs, is measured in Request Units, or RUs. An RU is an abstracted metric that represent the size and complexity of requests made to your cluster. In addition to queries that you run, background activity, such as automatic statistics to optimize your queries or connecting a changefeed to an external sink, also consumes RUs.
With CockroachDB Serverless, you are charged only for the storage and activity of your cluster. Cluster activity is measured in Request Units; cluster storage is measured in GiB and is based on the total amount of storage your cluster used over a billing period. Request Unit consumption scales to zero when your cluster has no activity.
RU and storage consumption is prorated at the following prices:
|1M Request Units||$0.20|
|1 GiB storage||$0.50|
Refer to Pricing to see cost estimates of common queries and how they increase with the size and complexity of the query. You can view your cluster's RU and storage usage on the Cluster Overview page.
Free vs. paid usage
CockroachDB Serverless clusters scale based on your workload so that you will only pay for what you use beyond the free resources. Each non-contract CockroachDB Cloud organization is given 50 million Request Units and 10 GiB of storage for free each month. Free resources do not apply to contract customers. Free resources can be spent across all CockroachDB Serverless clusters in an organization and will appear as a deduction on your monthly invoice.
Setting resource limits will allow your cluster to scale to meet your application's needs and maintain a high level of performance. You must set resource limits if you've already created one free CockroachDB Serverless cluster. To set your limits, you can either set storage and RU limits individually, or enter a dollar amount that will be split automatically between both resources. You can also choose an unlimited amount of resources to prevent your cluster from ever being throttled or disabled.
Choose resource limits
Your cluster's resource limits define the maximum amount of storage and RUs the cluster can use in a month.
- If you reach your storage limit, your cluster will be unable to write to its storage unless you delete data or increase your storage limit.
- If you reach your RU limit, your cluster will be disabled until you increase your RU limit or a new billing cycle begins.
The best way to estimate your resource usage is to set resource limits you're comfortable with and run your workload. You can see the RUs and storage your cluster has used in the Usage this month section of the Cluster Overview page. Once enough usage data is available, you can also see a graph of your monthly resource usage and recommended spend limit on the Edit cluster page.
SELECT query consumes between 1 and 15 RUs, depending on the amount of data it scans and returns. A typical
UPDATE statement consumes between 10 and 25 RUs, depending on the amount of data it inserts or updates. To estimate the RU consumption of individual SQL statements, you can use the
EXPLAIN ANALYZE SQL statement. For an example, see Example Request Unit calculation.
Cockroach Labs recommends setting your resource limits to about 30% higher than your expected usage to prevent cluster disruption. To learn about tuning your workload to reduce costs, refer to Optimize Your CockroachDB Serverless Workload.
You can create a CockroachDB Serverless cluster with up to six regions. When you create a multi-region cluster, you will be prompted to select a Primary region from which CockroachDB will optimize access to data. If you want to change your region configuration, you can use the Cloud Console, or you can back up and restore your data into a new cluster with the desired configuration.
You cannot currently edit the region configuration for a single-region cluster once it has been created, and you cannot remove a region once it has been added.
For optimal performance, deploy client applications in one of your cluster's configured regions. CockroachDB Serverless uses a geolocation routing policy to automatically route clients to the nearest region, even if that region is not one of your cluster's configured regions. This means that if you are running an application from a region that is not used by your cluster, connecting to that region may cause high network latency. This may be acceptable for development, but should be avoided for any production or performance-sensitive applications. Refer to the CockroachDB Serverless FAQs for information on overriding the automatic routing policy.
While multi-region CockroachDB Dedicated clusters must have a minimum of three regions, clusters can survive zone failures with only two regions. To survive a regional failure, a minimum of three regions is required.
Databases created in CockroachDB Serverless will automatically inherit all of a cluster's regions, so it is not necessary to run
ALTER DATABASE ... ADD REGION to configure regions when adding a database to the cluster. To override the default inheritance, you can specify the primary region with the
CREATE DATABASE <db_name> WITH PRIMARY REGION SQL syntax or the
Storage for a multi-region cluster is billed at the same rate as a single-region cluster. However, by default data is replicated three times in the primary region and once in each additional region, and each replica in the additional regions will accrue more storage costs. For example, a three-region cluster with data replicated five times will use 5/3 times the storage space of a single-region cluster where data is replicated three times.
- Write-heavy applications may experience a significant increase in RU consumption because replicating writes across all regions consumes more resources.
- Read-heavy applications may experience a smaller increase in RU consumption because the resources required to read from a single region of a multi-region cluster are comparable with a single-region cluster.
During the multi-region preview, RU usage for queries that cross regions will not account for inter-region bandwidth.