Bigtable Capacity Calculator
Work out how many Bigtable nodes your QPS, row size and stored data need, and what the cluster costs per month.
Inputs
Published per-node QPS figures assume 1 KB rows; larger rows are throughput bound instead.
Google recommends 70% for single-cluster and 35% for replicated instances.
Replication multiplies both nodes and storage — each cluster holds a full copy.
Nodes per Cluster
5nodes
Total Nodes in Instance
5nodes
Node Count Driven By
Request rate at your target CPU utilisation
Monthly Cost
$4,072.50
Node Charge
$2,372.50
Storage Charge
$1,700.00
Required Throughput
29.3MB/s
Cost per 1,000 QPS
$135.75
Step by step
Values used
Peak read QPS = 20,000 QPS; Peak write QPS = 10,000 QPS; Average row size = 1 KB; Data stored = 10 TB; Storage type = SSD (5 TB per node); QPS per node at 1 KB rows = 10,000 QPS; Throughput per node = 220 MB/s; Target CPU utilisation = 70 %; Price per node-hour = 0.6500 USD/node-hour; Hours in the billing month = 730 hours; SSD storage price per GB = 0.1700 USD/GB-month; HDD storage price per GB = 0.0260 USD/GB-month; Clusters in the instance = 1 clusters
Bigtable Capacity
nodes = max(QPS ÷ (QPS per node × target CPU), MB/s ÷ (MB/s per node × target CPU), TB ÷ per-node capacity), rounded up and multiplied by the cluster count.
Nodes per Cluster
= 5 nodes
Total Nodes in Instance
= 5 nodes
Node Count Driven By
= Request rate at your target CPU utilisation
Monthly Cost
= 4,072.50
Node Charge
= 2,372.50
Storage Charge
= 1,700.00
How it works
Bigtable sizing is the maximum of three independent limits: request rate, bytes per second and stored data. Row size decides which one binds — at 1 KB the QPS figure rules, but at 10 KB the same request rate is throughput bound and needs several times more nodes. Bigtable degrades ungracefully when it is short a node, showing up as latency spikes rather than errors, and replication doubles or triples the whole bill rather than just the compute. Confirm node-hour and per-GB prices for your region in the Google Cloud pricing calculator.
Formula
Bigtable Capacity
nodes = max(QPS ÷ (QPS per node × target CPU), MB/s ÷ (MB/s per node × target CPU), TB ÷ per-node capacity), rounded up and multiplied by the cluster count.
- QPS per node
- About 10,000 operations per second per node at 1 KB rows
- per-node capacity
- 5 TB on SSD, 16 TB on HDD before a node must be added
- cluster count
- Replicated instances hold a full copy per cluster, so nodes and storage both multiply
Frequently Asked Questions
How is Bigtable Capacity calculated?
nodes = max(QPS ÷ (QPS per node × target CPU), MB/s ÷ (MB/s per node × target CPU), TB ÷ per-node capacity), rounded up and multiplied by the cluster count. Bigtable sizing is the maximum of three independent limits: request rate, bytes per second and stored data. Row size decides which one binds — at 1 KB the QPS figure rules, but at 10 KB the same request rate is throughput bound and needs several times more nodes.
Why does Bigtable Capacity matter?
Bigtable degrades ungracefully when it is short a node, showing up as latency spikes rather than errors, and replication doubles or triples the whole bill rather than just the compute. Confirm node-hour and per-GB prices for your region in the Google Cloud pricing calculator.
What values do I need to enter?
This calculator takes 13 inputs: Peak read QPS, Peak write QPS, Average row size, Data stored, Storage type, QPS per node at 1 KB rows, Throughput per node, Target CPU utilisation, Price per node-hour, Hours in the billing month, SSD storage price per GB, HDD storage price per GB, Clusters in the instance. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Why does replication need a lower target CPU?
Because a replicated instance must be able to absorb the traffic of a failed cluster. Sizing each cluster to about 35% CPU leaves enough headroom for one cluster to take the whole load during a failover.