Bigtable Capacity Calculator
Work out how many Bigtable nodes your QPS, row size and stored data need, and what the cluster costs per month.
About Bigtable Capacity Calculator
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
Worked example
With the default values below, Bigtable Capacity Calculator returns Nodes per Cluster of 5. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Peak read QPSaccepts 0–10,000,000 QPS
- 20,000 QPS
- Peak write QPSaccepts 0–10,000,000 QPS
- 10,000 QPS
- Average row sizeaccepts 0.1–1,024 KB
- 1 KB
- Data storedaccepts 0–100,000 TB
- 10 TB
- Storage typeone of SSD (5 TB per node), HDD (16 TB per node)
- SSD (5 TB per node)
- QPS per node at 1 KB rowsaccepts 100–100,000 QPS
- 10,000 QPS
- Throughput per nodeaccepts 10–2,000 MB/s
- 220 MB/s
- Target CPU utilisationaccepts 20–90 %
- 70 %
- Price per node-houraccepts 0–100 USD/node-hour
- 0.65 USD/node-hour
- Hours in the billing monthaccepts 1–744 hours
- 730 hours
- SSD storage price per GBaccepts 0–5 USD/GB-month
- 0.17 USD/GB-month
- HDD storage price per GBaccepts 0–5 USD/GB-month
- 0.026 USD/GB-month
- Clusters in the instanceaccepts 1–8 clusters
- 1 clusters
Results
- 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
- Required Throughput
- 29.3 MB/s
- Cost per 1,000 QPS
- $135.75
Step by step
- 1Values used
- 2Bigtable Capacity
- 3Nodes per Cluster= 5 nodes
- 4Total Nodes in Instance= 5 nodes
- 5Node Count Driven By= Request rate at your target CPU utilisation
- 6Monthly Cost= 4,072.50
- 7Node Charge= 2,372.50
- 8Storage Charge= 1,700.00
Assumptions and limits
- The result is derived only from the 13 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
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.