SHARED HARNESS
Both systems used the same source dataset, schema, analytical workload, pacing model, query schedule, and result format. Destination-specific adapters handled delivery and timing. Part 1 explains the shared methodology; the BigQuery benchmark contract records this provider’s implementation.
DATASET AND PREPARATION
The complete NBBO dataset contains 113,219,565,734 narrow, 12-column rows. Raw tables used (sym, t), stock symbol and event timestamp; daily summaries used (sym, day), stock symbol and UTC day. The summaries maintained the counts, sums, and price minima and maxima used by the aggregate queries.
CONTINUOUS WORKLOAD
Fresh rows were paced toward 1 million per second while aggregate and drill-down queries ran on their ten-minute and hourly schedules. This models data generated continuously and prepared as it arrives. BigQuery’s max_staleness option was left unset, so MV queries had to include newer base-table data.
RECOMMENDED STACK AND SIZING
ClickHouse Cloud used a 16-CPU, 64-GiB read node. BigQuery used on-demand serverless query compute, with dynamically assigned slots and no fixed reservation. This is not a comparison of two fixed 16-CPU allocations. The Capacity alternative prices the same measured slot consumption at the Enterprise list rate; it does not represent a separate capacity run.
① PREPARATION COST
The full path includes ClickHouse’s complete two-node HA ingest service and BigQuery’s Storage Write API ingestion plus automatic MV refresh. BigQuery’s automatic reclustering has no separate charge. Both Capacity and On-demand preparation totals retain the same ingestion meter and price refresh resources under their respective compute models.
② QUERY COST AND ③ RUNTIME
ClickHouse query cost is recorded duration multiplied by its read-side compute rate. BigQuery Capacity uses job slot-seconds; On-demand uses billed bytes. Both BigQuery alternatives use the same recorded query durations for ③. These normalized costs describe accepted query work, rather than complete provider invoices.
TARGET VERSUS OBSERVED RATE
BigQuery acknowledged the full logical dataset in about 31.5 hours, averaging 999,495 rows/s; ClickHouse completed its ingest in about 36.75 hours, averaging approximately 0.86 million rows/s. The ingest summary records BigQuery’s acknowledged rows separately from the provider’s successful-write meter. That meter contains 113,172,471,254 successful rows; ClickHouse’s write-cost evidence contains 113,217,743,918 rows, a 0.040% difference. The query comparison uses the 113,219,565,734-row reference horizon.
REPORTING WINDOW
Per-query latency plots stop at 100 billion rows. Preparation costs retain the complete ingestion meter and collected refresh usage. Accumulated query cost and runtime use the accepted active-ingestion observations through the reference endpoint; later query observations are excluded. Displayed totals are rounded. The pricing note states the refresh-export boundary and exclusions.
PRICING BASIS
ClickHouse Cloud uses $0.3903 per compute unit (CU) per hour. BigQuery uses the checked-in US list rates: $0.025/GiB for Storage Write API ingestion, $0.06/slot-hour for Enterprise Capacity, and $6.25/TiB for On-demand analysis. The accepted summary retains full-precision inputs. Capacity and On-demand are alternative modeled costs for the same jobs.
① COMPLETE PREPARATION COST
This covers the complete streaming-ingestion meter, automatic reclustering at no separate charge, and the collected MV-refresh usage.
CLICKHOUSE CLOUD
2 CUs × 36.75 hours × $0.3903/CU-hour = $28.68705, including both HA ingest nodes.
BIGQUERY INGESTION
The Write API meter records 9,642.7384687 GiB × $0.025/GiB = $241.06846172, using successful input bytes. Client-acknowledged Arrow bytes and provider-metered input bytes are distinct measures.
BIGQUERY CLUSTERING
Automatic reclustering is included without a separate charge. No paid manual reorganization job is added.
BIGQUERY MV REFRESH
The 362-job export contains 121,166.568 slot-seconds, priced at $0.06/slot-hour for $2.0194428, or 4,137,783,656,448 billed bytes, priced at $6.25/TiB for $23.52057695. Preparation totals are $243.08790452 Capacity and $264.58903867 On-demand.
② NORMALIZED QUERY COST
BigQuery prices the same accepted query jobs by consumed slot-seconds or billed bytes. ClickHouse prices recorded duration at its read-side rate.
CLICKHOUSE CLOUD
8 CUs × $0.3903/CU-hour × (10.324s aggregate + 47.962s drill-down) ÷ 3,600 ≈ $0.05055, using the rounded cost-summary inputs.
BIGQUERY CAPACITY
Aggregate jobs cost $4.29558297 and drill-down jobs $0.45264198, totaling $4.74822495. The combined 79.1370825 slot-hours × $0.06/slot-hour allocation uses recorded job slot consumption.
BIGQUERY ON-DEMAND
Aggregate jobs cost $20.94800472 and drill-down jobs $3.85683775, totaling $24.80484247. The combined billed volume is 3.9687748 TiB × $6.25/TiB. This is an alternative to Capacity pricing, not an added component.
COST BOUNDARY
The preparation model keeps the full successful-write meter and all 362 collected refresh jobs, including the terminal refresh after producer completion. Query totals exclude later post-ingestion observations and evidence-collector jobs. Database storage, free tiers, discounts, idle/minimum capacity charges, producer infrastructure, and network charges are excluded.
③ ACCUMULATED QUERY RUNTIME
ClickHouse: 10.324s aggregate + 47.962s drill-down = 58.286s. BigQuery: 2,751.868s aggregate + 209.518s drill-down = 2,961.386s under either pricing model.
COMPARISON BOUNDARY
① retains complete-ingest preparation usage. ② and ③ use 190 four-query aggregate batches and 33 two-query drill-down batches, aligned by row progress through the reference horizon. Latency statistics use the separate 100-billion-row window. The Capacity alternative changes the price applied to measured resources; it does not change query hardware or rerun the workload.
FINAL SCORES
ClickHouse: ($28.68705 + $0.05055) × 58.286 = 1,674.99975. BigQuery Capacity: ($243.08790452 + $4.74822495) × 2,961.386 = 733,938.44411, a 438.172× ratio. BigQuery On-demand: ($264.58903867 + $24.80484247) × 2,961.386 = 857,006.98809, a 511.646× ratio. Headline values round to 438× and 512×.
The ClickHouse writer-utilization results show ingestion continuing alongside background maintenance. CPU usage remained around 3.1 of the 4 available cores, tracked memory stayed within capacity, background merges processed several million rows per second, and the maximum active-part count per partition stayed around 100. These diagnostics describe the ClickHouse source run reused for this comparison.
Both nodes were retained for high availability, so the preparation cost includes the complete two-node deployment.
THE SAME INGESTION PROBLEM
Frequent application writes must become efficient storage writes. ClickHouse buffered INSERT requests on its ingest nodes. BigQuery accepted Arrow batches through committed Storage Write API streams, without a Kafka broker or file landing stage in the measured path.
BIGQUERY’S STREAMING PATH
The full-run configuration used 40 committed streams, explicit row offsets, 131,000-row client batches, and a 16,000,000-byte request limit. A global rate controller paced append starts toward 1 million rows/s. Successful acknowledgments, rather than rows merely read from Parquet, defined progress.
CLICKHOUSE’S NATIVE PATH
Ordinary INSERT requests with async_insert enabled were buffered on each receiving node. An adaptive flush timeout responded to incoming traffic. Ordering and pre-aggregation ran on the ingest nodes; the dedicated ingest service shared storage with the independently sized read service.
SHARED PACING
Both adapters read the same Parquet dataset and decoded the same schema under the same target-rate model. Parallelism and client batch sizes were adapted to each destination’s API; they were not forced to be identical.
CLICKHOUSE BATCHES
The client sent 3,000-row batches through asynchronous inserts. Default buffering flushed at the first of three thresholds: 100 MiB buffered, an adaptive timeout between 50 milliseconds and 1 second, or 450 queued insert queries.
BIGQUERY BATCHES
Each worker owned one committed stream and sent serialized Arrow record batches. This was live streaming delivery; rows were not uploaded as files for a later load job. No pending-stream batch commit was used.
BATCH-SIZE BOUNDARY
The 3,000-row ClickHouse and 131,000-row BigQuery sizes describe client delivery. They do not specify the final MergeTree part or BigQuery storage-block size.
RETRIES AND RECONCILIATION
Explicit offsets let BigQuery detect an exact replay after a lost acknowledgment. The client contract counts a confirmed replay once and reconnects. This provides exactly-once retry handling within the live run, rather than crash-resumable source checkpointing. Client acknowledgments, provider successful-write rows, and table metadata are kept as distinct evidence.
INCREMENTAL MAINTENANCE
The MV definition used supported COUNT, MIN, MAX, and SUM operations over an append-only source. The refresh-job export contains 362 successful automatic refresh jobs with no failed jobs. Refresh slot-seconds and billed bytes are recorded independently from the dashboard jobs.
LAYOUT AND PARTITIONING
The raw table was deliberately unpartitioned because D1 and D2 filter by symbol across the full ingested history, without a time predicate. Clustering on (sym, t) serves that workload. Automatic reclustering is managed and free of a separate compute charge; a manual rewrite was not added to the benchmark.
BIGQUERY SERIES
The freshness monitor sampled refresh_watermark once a minute. Lag is the elapsed time from that watermark to the observation. 1,889 active samples are included through the first full-row observation; 441 later samples are excluded. This is a maintenance-watermark measure, not answer staleness.
DISPLAY AND READOUTS
The chart selects one measured maximum from each fully observed refresh-watermark cycle, producing 359 cycle peaks. The first and last partial cycles are excluded. Their mean is 4.861 minutes and maximum 6.100 minutes, rounded to 4.9 and 6.1. The full active raw series has an 8.023-minute startup peak that is outside this cycle-peak display. Readouts follow the displayed curve.
CLICKHOUSE BASELINE
The zero line is a benchmark-semantic baseline, not a separately polled provider metric. The raw table and incremental MV consume the same flushed insert block, with no independent summary-refresh interval between them. It does not claim zero source-to-query ingestion delay.
CURRENT-ANSWER CONTRACT
With max_staleness unset, a direct materialized-view query includes base-table changes not yet represented in the MV. A lagging refresh watermark does not mean that the returned answer is stale. It means some of the preparation remains on the query path.
REFRESH CONTRACT
The one-minute refresh interval is a frequency cap. Automatic refresh is best effort and can complete less often under load. Refresh-watermark lag and query latency are measured separately; the benchmark does not assign the entire latency gap to delta processing.
COMPUTE CONTRACT
The measured jobs ran on on-demand, dynamically allocated slots. Enterprise Capacity pricing applies $0.06 per slot-hour to the measured job slot-seconds. It does not replay the jobs on a fixed reservation or change their measured latencies.
ON-DEMAND CONTRACT
The alternative applies $6.25 per TiB to each job’s billed bytes. Bytes and slot-seconds describe the same jobs under different pricing conventions; their costs are never added together.
VISIBILITY BOUNDARY
A successful committed append makes rows queryable, while table metadata can update later. The runner’s progress signal uses acknowledged rows. Queryability, metadata updates, clustering, and summary refresh remain distinct milestones.
QUERY DEFINITIONS
Part 1 describes A1-A4 and D1-D2. The BigQuery SQL preserves the symbol filters, full-history scope, grouping, ordering, and limits. D2 uses population central moments and APPROX_QUANTILES for percentiles; the percentile algorithm differs from ClickHouse’s quantilesTDigest and requires tolerance-based comparison.
CACHE POLICY
Query-result caching was disabled with use_query_cache=False. Underlying data caches were allowed to operate normally; they were not flushed between queries.
TIMING
BigQuery latency is the completed job’s finalExecutionDurationMs divided by 1,000; ClickHouse uses its recorded runner duration. Median, P99, and maximum pool unsmoothed per-query observations with 0 < raw_rows ≤ 100 billion. P99 uses linear interpolation. The recorded timing convention is retained in accumulated runtime.
LATENCY CHARTS
Each system is plotted at its own observed ingestion progress. Aggregate trends use a centered seven-observation rolling median; drill-downs use five observations, with shrinking edge windows. No outliers are removed. The curves are display smoothing; the statistics and accumulated totals use the original recorded durations.
INTERACTIVE READOUTS
Values below the plots follow the displayed trends at the selected row count. Logarithmic scales keep milliseconds and seconds readable together; Linear shows absolute differences. Each chart has its own playback and row-position controls.
ACCEPTED ACCUMULATED WORKLOAD
The selection contains 190 four-query aggregate batches and 33 two-query drill-down batches per system: 760 + 66 = 826 executions. ClickHouse observations are aligned with BigQuery row progress through the 113,219,565,734-row reference horizon. The initial observation is retained where present; later post-ingestion observations are excluded.
ACCUMULATED CHARTS
Query durations are added at corresponding ingestion counts as step sums, without smoothing or interpolating future executions into earlier positions. Preparation-cost lines allocate the complete-ingest total proportionally by row progress; they are not metered cost-at-time traces. The score sums query durations, not elapsed ingestion time.