GCP Bigtable SSD vs HDD cost: choosing the storage type

Quick answer

Bigtable charges separately for nodes and storage, and you choose SSD or HDD storage per cluster. Nodes cost the same for both, roughly 0.65 dollars per hour, about 474 dollars per month per node, but storage differs sharply: SSD storage costs about 0.17 dollars per GB per month while HDD storage costs about 0.026 dollars per GB per month, roughly six times cheaper. SSD delivers much lower latency and higher throughput, while HDD suits large, throughput-oriented, latency-tolerant datasets. The rule is use SSD for latency-sensitive serving workloads and HDD only for very large, cold, batch-scan datasets where the storage saving outweighs the performance loss.

Bigtable's cost has two parts, nodes and storage, and the storage type you choose has a large effect on the storage half. You pick SSD or HDD when you create a cluster, and while the node cost is identical, SSD storage costs many times more per gigabyte than HDD. For a data-heavy workload, that difference can dominate the bill, so the choice deserves thought rather than defaulting to SSD.

SSD vs HDD on cost and performance

Factor	SSD	HDD
Storage cost	About 0.17 dollars per GB per month	About 0.026 dollars per GB per month
Node cost	About 0.65 dollars per hour	About 0.65 dollars per hour
Latency	Low, single-digit milliseconds	Higher
Best for	Latency-sensitive serving	Large cold batch scans

The node rate is the same for both storage types, so the difference is entirely in storage: SSD at about 0.17 dollars per GB per month versus HDD at about 0.026 dollars, roughly a six-fold gap. For a cluster storing many terabytes, that gap is enormous. Ten terabytes on SSD costs around 1700 dollars a month in storage, while on HDD it costs around 260 dollars, a difference far larger than most node costs.

Why not always choose HDD

The catch is performance. SSD delivers low, predictable latency and high throughput, which is what most Bigtable serving workloads need. HDD has much higher latency and lower throughput, especially for random reads, so it is unsuitable for latency-sensitive applications. HDD shines only for large datasets accessed through infrequent batch scans, where throughput matters more than per-request latency and the data is essentially cold. Choosing HDD for a serving workload trades a storage saving for latency your users will feel.

When HDD is the right call

HDD is the right choice when you have a very large dataset, terabytes and up, that is accessed mostly through sequential batch processing rather than random point reads, and where higher latency is acceptable. Archival time-series data scanned periodically, large historical logs, and similar cold, scan-heavy datasets fit the HDD profile, and the storage saving at that scale is substantial. Below a certain dataset size, the storage saving is too small to justify the performance hit, so SSD remains the default for most clusters.

Choosing and sizing

Default to SSD for serving workloads and reserve HDD for very large, cold, scan-oriented datasets where the six-fold storage saving clearly outweighs the latency cost. Size nodes to throughput, since both storage types share the node rate, and keep an eye on storage growth, which is billed per GB independently of nodes. The storage type cannot be changed in place, so choose deliberately up front. Price both SSD and HDD configurations against the resource catalog so the storage-type decision is costed before the cluster is built.

FAQ

What is the cost difference between Bigtable SSD and HDD?

Nodes cost the same for both, roughly 0.65 dollars per hour, but storage differs sharply: SSD storage costs about 0.17 dollars per GB per month while HDD costs about 0.026 dollars per GB per month, roughly six times cheaper. At ten terabytes, SSD storage costs around 1700 dollars a month versus around 260 dollars for HDD, a large difference for data-heavy clusters.

When should I use HDD storage for Bigtable?

When you have a very large dataset, terabytes and up, accessed mostly through sequential batch scans rather than random point reads, and where higher latency is acceptable. Archival time-series data, large historical logs, and similar cold, scan-heavy datasets fit the HDD profile, and the roughly six-fold storage saving at that scale is substantial.

Why not use HDD for everything to save money?

Because HDD has much higher latency and lower throughput, especially for random reads, making it unsuitable for latency-sensitive serving workloads. SSD delivers low, predictable single-digit-millisecond latency that most Bigtable serving workloads need. Choosing HDD for a serving workload trades a storage saving for latency your users will feel, so SSD remains the default for most clusters.

Can I change Bigtable storage type after creating a cluster?

No. The storage type is chosen when you create the cluster and cannot be changed in place, so you must decide deliberately up front. Migrating between types requires creating a new cluster with the desired storage type and moving the data, which is why costing both SSD and HDD options before building the cluster is worthwhile.

How does C3X help with Bigtable storage cost?

C3X prices your Bigtable configuration from Terraform before you deploy, including nodes and the chosen SSD or HDD storage, so the storage-type cost difference is visible in the pull request. That lets you compare SSD and HDD for your dataset size and access pattern at design time, choosing the right storage type before the cluster is built rather than discovering the storage bill later.

What to do next

Compare Bigtable storage types on cost before you build the cluster. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.