Plan a CockroachDB Basic Cluster

This page describes how resource usage, pricing, and cluster configurations work in CockroachDB Basic. For information on diagnosing and optimizing your resource consumption, see .

​

Request Units

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 represents the used by a database operation. In addition to queries that you run, background activity, such as automatic statistics to optimize your queries or running a changefeed to an external sink, also consumes RUs. You can review how many request units your cluster has used on the .

​

Pricing

With CockroachDB Basic, 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: 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 .

​

Free vs. paid usage

CockroachDB Basic clusters scale based on your workload so that you will only pay for what you use beyond the free resources. Each pay-as-you-go CockroachDB Cloud organization - those paying monthly by credit card or marketplace - is given $15 of resource consumption (equivalent to 50 million Request Units and 10 GiB of storage) for free each month. Every monthly billing cycle, this free monthly resource benefit can be spent across all CockroachDB Basic clusters in an organization. The free usage appears as a $15 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 if you’ve already created one free CockroachDB Basic 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 determines the (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 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 page. Once enough usage data is available, you can also see a graph of your monthly resource usage and recommended spend limit on the page. A typical SELECT query consumes between 1 and 15 RUs, depending on the amount of data it scans and returns. A typical INSERT or 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 SQL statement. For an example, see . 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 . Each will receive email alerts when a cluster reaches 50%, 75%, and 100% of its .

​

Multi-region clusters

When you create a multi-region Basic 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, , or you can your data into a new cluster with the desired configuration. For optimal performance, deploy client applications in one of your cluster’s configured regions. CockroachDB Basic 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. While multi-region CockroachDB Advanced clusters must have a minimum of three regions, Basic clusters can survive with only two regions. To survive a , a minimum of three regions is required. Databases created in CockroachDB Basic will automatically inherit all of a cluster’s regions, so it is not necessary to run to configure regions when adding a database to the cluster. To override the default inheritance, you can specify the primary region with the SQL syntax or the setting. 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. Cross-region operations consume RUs for cross-region networking. Cross-region networking costs depend on the source and destination regions. For read operations, the source region contains the replica and the destination region is the gateway region. For write operations, the source region is the gateway region and the destination region contains the replica. There is a network charge for each replica to which an operation writes. Refer to Pricing for a matrix of cross-region costs. Keep in mind the following key points when planning your multi-region CockroachDB Basic application’s architecture:

• 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.
• Cross-region reads are an anti-pattern and may significantly increase RU consumption. Features such as , , and help avoid most cross-region reads.
• Cross-region writes will also consume additional RUs, but should not significantly increase consumption.