europe-west3 (Frankfurt) · USD list prices · verified 2026-06/07 · zonal, no CUD, no HA
1 · Storage economics by dataset size
Pure $/month for stored bytes, log scale. Cloud SQL storage cannot exist without an instance — this isolates the per-GiB gap only.
Cloud SQL SSDBQ activeBQ long-term
Cloud SQL SSD ~$0.219/GiB · BigQuery active logical $0.023/GiB · long-term logical $0.016/GiB (untouched 90+ days, automatic).
Cloud SQL storage is ~9.5× BigQuery active and ~13.7× long-term — before any instance cost.
2 · Total cost by access intensity — 1 TiB dataset
The real comparison. Cloud SQL is flat (24/7 instance + storage); BigQuery on-demand grows with bytes scanned. X-axis: full-table-scan equivalents per month.
break-even: ~57 scans/mo vs 4 vCPU · ~89 scans/mo vs 8 vCPU
BigQuery = $23.55 storage + $8.125/TiB scanned (Frankfurt on-demand — 30% above the US $6.25; 1 TiB free tier excluded, assumed consumed at billing-account level).
Cloud SQL flat lines: 4 vCPU/16 GB = $484 · 8 vCPU/32 GB = $745 (compute + 1 TiB SSD).
"Full-scan equivalents" is pessimistic for BQ — partitioning, clustering and column pruning mean real queries scan a fraction of the table.
3 · Latency by operation class
Order-of-magnitude architectural characteristics, not benchmarks. Log scale, milliseconds.
Cloud SQL (PostgreSQL)BigQuery
Mechanism: Cloud SQL is a single-node B-tree row store — index-bound operations land in single-digit ms, but scans are bound by one machine's I/O and CPU, so a 1 TiB aggregation runs into minutes. BigQuery is a distributed columnar engine — every query pays a ~1–2 s floor (slot scheduling, plan, shuffle setup), but scan work parallelizes across thousands of slots, so latency stays near-flat as data grows. BQ DML is batch-oriented; row-level mutation is an anti-pattern there (use Storage Write API for streaming ingest instead).
Consequence: OLTP/point-access workloads → Cloud SQL; analytical scans → BigQuery. The cost crossover in diagram 2 only matters inside the workload class where both are viable.
4 · Price-performance index by operation class
Monthly cost × latency, normalized per class to the best configuration (= 1). Lower is better. Log scale — bars read as "×N worse than the best option for this workload". Five configurations across seven operation classes.
Method: index = monthly cost (1 TiB dataset; Cloud SQL compute + storage, BigQuery storage + N full-scan equivalents) × typical latency from diagram 3's model, divided by the per-class minimum. Latency mechanics: OLTP operations are index-bound, so 4 vs 8 vCPU is nearly irrelevant — the cheaper instance wins those classes. Scan-bound operations roughly halve in latency with doubled cores. BigQuery latency is identical across its levels — only cost changes — so lighter query budgets always index better at equal speed.
Reading: on OLTP-shaped classes even the cheapest BQ level is ~25–120× worse than Cloud SQL — the three-orders-of-magnitude latency gap dominates any cost advantage. On the dashboard and full-scan classes the picture inverts: Cloud SQL is ~10–4,500× worse depending on instance and BQ budget. This is a heuristic (assumes linear cost/speed tradeoff); magnitudes shift with assumptions, the class inversion doesn't.