Google CloudGoogle Cloud BigtableDatabase

`google_bigtable_instance` cost estimation

Wide-column NoSQL for low-latency, high-throughput workloads. $0.65/node-hour (SSD) or $0.17/node-hour (HDD) plus storage. 3-node minimum production. Replication to another region doubles node cost.

Google Cloud Bigtable is the wide-column NoSQL database used internally for Search, Maps, Gmail. The google_bigtable_instance resource creates the instance; clusters and tables are separate. Pricing has two components: nodes and storage.

Node pricing: - SSD nodes: $0.65/hour ($474/month per node) - HDD nodes: $0.17/hour ($124/month per node) - 3-node minimum for production SLA (single-node clusters allowed but unsupported for production)

Storage pricing: - SSD: $0.17/GB-month - HDD: $0.026/GB-month

A typical 3-node SSD Bigtable cluster: 3 × $474 = $1,422/month minimum for compute. Plus storage at $0.17/GB-month (~$170 for 1 TB).

Replication doubles cost: a 3-node primary + 3-node replica in another region = $2,844/month for compute alone, plus duplicated storage.

When Bigtable wins: - Time-series data at petabyte scale - High-write workloads (10K+ writes/second sustained) - Predictable schema (row key + column families) - Workloads benefiting from sequential access on row keys

When Bigtable is wrong: - OLTP with complex queries (no JOINs, no secondary indexes natively) - Small datasets (3-node minimum makes it expensive) - Workloads needing strong cross-row consistency

Compared to alternatives: DynamoDB pay-per-request scales to zero, while Bigtable's 3-node minimum is ~$1,400/month always-on. For workloads under ~10K requests/second, DynamoDB or Firestore is usually cheaper.

c3x estimates Bigtable based on cluster configurations (num_nodes, storage_type) and the displayed storage allocation.

Terraform example

A minimal but realistic configuration that C3X can estimate.

resource "google_bigtable_instance" "main" {
  name = "production-bigtable"

  cluster {
    cluster_id   = "main-cluster"
    zone         = "us-central1-b"
    num_nodes    = 3
    storage_type = "SSD"

    autoscaling_config {
      min_nodes      = 3
      max_nodes      = 10
      cpu_target     = 70
      storage_target = 8192
    }
  }

  cluster {
    cluster_id   = "replica-cluster"
    zone         = "us-east1-b"
    num_nodes    = 3
    storage_type = "SSD"
  }
}

Pricing dimensions

What you actually pay for when you provision google_bigtable_instance.

Dimension	Unit	What's being charged
SSD node hours	per node-hour	Compute hours for SSD-backed Bigtable nodes. 3-node minimum for production. $0.65/node-hour ($474/month)
HDD node hours	per node-hour	HDD-backed nodes for cold/archival workloads. Lower performance but ~75% cheaper. $0.17/node-hour ($124/month)
SSD storage	per GB-month	Storage allocated on SSD-backed clusters. $0.17/GB-month
HDD storage	per GB-month	Storage allocated on HDD-backed clusters. $0.026/GB-month
Replication network	per GB	Data transfer between clusters for replication. Standard inter-region transfer rates. $0.01-$0.12/GB depending on regions

Optimization tips

Common ways to reduce google_bigtable_instance cost without changing the workload.

Use HDD for cold/archive workloads

74% on nodes, 85% on storage

HDD nodes are 4x cheaper ($0.17 vs $0.65/hour). Right for archival data, append-only logs, time-series with rarely-accessed history. Don't use for latency-sensitive workloads (HDD scan latency is 10x SSD).

Enable autoscaling

30-50% on nodes

Autoscaling adjusts node count based on CPU/storage. Workloads with daily patterns benefit: scale up for business hours, down for nights. Saves ~30-50% on node hours.

Single-cluster for dev/test

50% on dev clusters

Production-grade replication needs two clusters. Dev/test environments can run single-cluster, halving compute cost. Keep production replicated for HA.

Use committed use discounts

20-40% on commitment

1-year commits save 20% on Bigtable nodes. 3-year commits save 40%. For steady production workloads, commits are essentially free money.

Right-size cluster minimum

67% on non-SLA workloads

3 nodes is the production SLA minimum, but autoscaling can scale to fewer (1-2) during low load if SLA isn't critical. For non-SLA workloads, single-node clusters work and cut cost 67%.

FAQ

Is the 3-node minimum a hard requirement?

No, you can run 1-node clusters. But the production SLA (99.9%/99.99%) requires 3+ nodes per cluster. Single-node clusters are fine for development. For production workloads, the 3-node minimum effectively locks you into $1,400/month per cluster.

When is Bigtable cheaper than DynamoDB?

At very high sustained throughput. DynamoDB on-demand bills per-request; for 10K+ writes/second 24/7, the request fees add up. Bigtable's per-node cost is fixed regardless of QPS, so beyond ~10K writes/second sustained, Bigtable becomes cheaper. For bursty/low-throughput, DynamoDB wins.

How does Bigtable HDD compare to BigQuery for analytics?

Different use cases. Bigtable HDD is a transactional database with low-latency lookups. BigQuery is a data warehouse for analytical queries. For 'look up specific rows by key' workloads, Bigtable HDD is right. For 'aggregate across all data', BigQuery is right (and cheaper for query-heavy workloads).

Does autoscaling really save money?

Significantly, for variable workloads. A workload with 70% CPU peak and 20% off-peak: without autoscaling, you provision for peak. With autoscaling, average node count is much lower. For perfectly steady workloads, autoscaling doesn't help — you're always at the same node count.