50.3k
TL;DR
Real-time systems vary dramatically in the cost and efficiency of carrying incoming data from arrival to query readiness. In this series, we follow that path to see how it shapes preparation cost, query cost, and query runtime.
Here, ClickHouse Cloud and BigQuery ingest 113.2 billion quotes while queries run. ClickHouse Cloud delivered 438× better end-to-end performance per dollar under BigQuery Capacity pricing, and 512× under On-demand pricing. The comparison traces where those differences begin.
From fresh data to fast answers
Real-time analytics must keep answering quickly as new data arrives. CostBench tests that directly: queries run throughout continuous ingestion, and answers include newly arrived data. Preparing that data efficiently lowers the cost of keeping it query-ready and leaves less work for queries, reducing their cost and runtime.
Columnar storage lets queries skip unused fields; ordering lets drill-downs skip unrelated quotes; current pre-aggregations let interactive aggregations combine prepared summaries. The diagram below follows how the fresh-data path changes query work as preparation keeps up or falls behind.
CostBench measures ① preparation cost, ② query cost, and ③ runtime, then combines them into one end-to-end performance-per-dollar score.
This article follows those three effects through the ClickHouse-BigQuery comparison, from preparing incoming data to serving queries.
The workload and the result
ClickHouse Cloud delivered 438× better end-to-end performance per dollar than BigQuery under Capacity pricing, and 512× under On-demand pricing, while ingestion and queries ran together.
Both systems used their recommended real-time ingestion paths and native preparation features: ClickHouse asynchronous inserts; BigQuery Storage Write API committed streams, clustering, and incremental materialized views. CostBench streamed 113.2 billion stock-market quotes at a target of 1 million rows per second, with equivalent sorting or clustering keys and daily pre-aggregations by stock symbol. Throughout ingestion, four interactive aggregate queries ran every ten minutes; two drill-down queries over raw quotes ran every hour. Each query covered the history ingested so far, including newly arrived quotes. Query-result caching was disabled.
CostBench calculates its end-to-end performance-per-dollar score using the formula shown below: Score = (① preparation cost + ② normalized query cost) × ③ accumulated query runtime.
Preparation cost covers the complete fresh-data path. Normalized query cost prices the resources consumed by the queries; accumulated query runtime is the sum of their durations. Lower scores are better. BigQuery Capacity and On-demand are alternative prices for the same measured workload, with the same query latencies.
HOW DID WE MEASURE ① ② ③? (click to expand)
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.
ClickHouse Cloud led in all three measured components:
① Preparation cost: $28.69 versus $243.09 Capacity / $264.59 On-demand.
② Normalized query cost: about $0.05 versus $4.75 Capacity / $24.80 On-demand.
③ Accumulated query runtime: 58.29 seconds versus 49.36 minutes under either BigQuery pricing model.
The charts below show how those costs and runtimes accumulated while data arrived.
The next chart applies the score formula to those components: ClickHouse’s 8.62× lower combined cost under Capacity pricing, or 10.07× lower under On-demand, combines with 50.8× lower accumulated query runtime.
PRICING, FORMULAS, AND THE 438× / 512× SCORES (click to expand)
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×.
438× better real-time performance per dollar
Interested in seeing how ClickHouse works on your data? Get started with ClickHouse Cloud in minutes and receive $300 in free credits.
Sign upAll benchmark code and results are available in the CostBench repository. The stock-quotes dataset requires a separate data license, so the data itself cannot be redistributed.
To explain that result, we follow the same path as the data: preparation first, then query serving.
How ClickHouse Cloud prepares incoming data
The benchmark used a dedicated ClickHouse Cloud ingest service with two 2-CPU nodes for high availability, the smallest HA configuration that sustained the target during calibration. The shared client sent rows through asynchronous inserts built into each node.
The diagram below shows those same nodes handling ① columnar storage, ② ordering raw data, and ③ ordered pre-aggregation, plus background merges, on four CPU cores in total.
① Store in columns and ② order data: When an ingest node flushes its asynchronous-insert buffer, it sorts raw quotes by the MergeTree table’s (sym, t) key, stock symbol and event timestamp, and writes an ordered data part.
③ Order and pre-aggregate data: The same node runs the incremental MV query over the incoming block in memory, computes aggregate states, and sorts the results by the AggregatingMergeTree table’s (sym, day) key before writing an ordered part containing the summaries.
Background merges consolidate parts in both tables.
The result: raw data and pre-aggregations advance together from the same flushed insert block, without a separate refresh cycle.
HOW MUCH WORK DID THE FOUR-CORE INGEST SERVICE HANDLE? (click to expand)
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.
Now follow the same three preparation tasks through BigQuery, where streaming ingestion, clustering, and MV refresh advance separately.
How BigQuery prepares incoming data
The benchmark used BigQuery’s Storage Write API with application-created committed streams, sending Arrow record batches over long-lived gRPC connections. Successful appends made the rows available for queries.
As shown below, the streaming path handles ① columnar storage, while BigQuery manages ② clustering and ③ incremental MV refresh asynchronously.
① Store in columns: The Storage Write API delivers rows into a native BigQuery table. BigQuery manages columnar storage separately from query compute; an acknowledged committed append does not guarantee that the table’s clustering is fully optimized.
② Order data: The raw table used CLUSTER BY sym, t, giving symbol filters a way to prune storage blocks. BigQuery maintains that layout with automatic reclustering; it does not guarantee that every appended batch is already ordered.
③ Order and pre-aggregate data: A native incremental MV grouped quotes by (sym, day), maintaining counts, sums, and price extrema, with the same clustering key. Automatic refresh was enabled with refresh_interval_minutes = 1, the minimum supported interval. This allows automatic refreshes no more often than once per minute; it does not guarantee that summaries become current within one minute.
The result: BigQuery can make new rows queryable before clustering catches up, while pre-aggregations advance through a separate refresh cycle.
WHY THESE INGESTION PATHS, AND HOW WERE THEY BUFFERED? (click to expand)
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.
What this means for freshness and preparation cost
Pre-aggregation lag
ClickHouse updates summaries during inserts; BigQuery refreshes them asynchronously. The chart below shows one observed lag maximum per complete refresh cycle: BigQuery’s plotted cycle peaks average 4.9 minutes and reach 6.1 minutes. ClickHouse’s raw data and summaries advance together in this setup.
This measures summary maintenance lag. BigQuery still returns current MV answers by including newer base-table rows at query time.
HOW WAS PRE-AGGREGATION LAG MEASURED? (click to expand)
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.
ClickHouse maintained summaries alongside raw data; BigQuery’s plotted refresh-cycle lag peaks averaged 4.9 minutes, leaving newer rows to be included at query time.
Those newer rows add work to queries. First, compare the cost of the preparation path itself.
Cost of keeping incoming data query-ready
ClickHouse handles ① columnar storage, ② ordering raw data, and ③ ordered pre-aggregation within its engine. BigQuery combines separately priced streaming ingestion and MV maintenance; automatic reclustering adds no separate charge. The chart below compares the complete preparation costs under both BigQuery pricing models.
ClickHouse’s complete ingest service cost $28.69. BigQuery’s Storage Write API cost $241.07 (①); automatic reclustering (②) had no separate charge. MV refresh (③) adds $2.02 under Capacity pricing or $23.52 under On-demand, giving preparation totals of $243.09 and $264.59, respectively.
ClickHouse handled the complete preparation path at 8.5× lower cost than BigQuery Capacity, and 9.2× lower than On-demand.
Now follow the raw data and summaries into query serving.
How ClickHouse Cloud serves queries
Ordered raw data lets drill-downs skip unrelated rows; pre-aggregations let interactive aggregations combine prepared results instead of recalculating them from individual quotes. The diagram below shows both paths through ClickHouse Cloud’s read service: one node with 16 CPUs and 64 GiB of memory.
Drill-downs: Queries prune ordered raw data in the event-level MergeTree table. Filtering by symbol, the leading column of its (sym, t) sorting key, lets the read service skip unrelated quotes.
Interactive aggregations: Queries read current pre-aggregations from the AggregatingMergeTree table, combining prepared counts, sums, minima, and maxima from a much smaller set of daily summary rows. There is no independent refresh to wait for.
The result: drill-downs prune ordered raw data; interactive aggregations read summaries kept current during ingestion.
BigQuery follows the same two query paths, with additional work when clustering or summary refresh falls behind.
How BigQuery serves queries
The diagram below follows both workloads through BigQuery’s serverless compute pool. Slots are assigned dynamically; there is no dedicated warehouse with a fixed CPU count in this run.
Drill-downs: Queries read the clustered raw table directly. Filtering on sym can prune unrelated blocks, but newly arrived data may need scanning before reclustering has optimized its layout.
Interactive aggregations: Queries target the incremental MV and combine its summaries with changes added to the base table since the last refresh. This catch-up work keeps answers current even when the MV watermark trails incoming data.
Both paths can therefore encounter unfinished preparation: drill-downs may scan data whose clustering is incomplete; aggregate queries must include rows that refresh has not yet summarized.
HOW DO BIGQUERY’S CURRENT ANSWERS AND COMPUTE MODELS WORK? (click to expand)
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.
The result: BigQuery drill-downs can scan newly arrived data before clustering catches up; interactive aggregations include the newer rows its summaries have not yet incorporated.
What this means for query performance and cost
Drill-downs over ordered raw data
Both systems used (sym, t) keys, with ClickHouse ordering rows during inserts and BigQuery managing clustering asynchronously. D1 and D2 investigate one stock’s growing history directly: hourly price summaries and a risk-and-liquidity profile. The chart below follows this raw-data path, bypassing the pre-aggregation MV.
ClickHouse Cloud is yellow; BigQuery is blue.
HOW WERE QUERY LATENCIES AND ACCUMULATED RESULTS COMPARED? (click to expand)
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.
ClickHouse Cloud:
- 722.5 ms median - 4.47× faster than BigQuery
- 1.15 s P99 - 3.90× faster
- 1.18 s maximum - 4.05× faster
Accumulated runtime was 47.96 seconds across the 33 two-query batches. Both drill-downs stayed near or below one second for most of the plotted window.
BigQuery:
- 3.232 s median
- 4.49 s P99
- 4.78 s maximum
Accumulated runtime was 209.52 seconds across the same 33 batches. Both BigQuery drill-downs remained in the multi-second range as the raw table grew.
Across the drill-down workload, ClickHouse Cloud was 4.37× faster overall.
Interactive aggregations over ordered pre-aggregated data
Daily pre-aggregations let A1-A4 combine prepared counts, sums, and price minima and maxima. A1-A2 filter summaries by symbol; A3-A4 read across all symbols. ClickHouse reads current summaries; BigQuery must also include newer base-table rows. The chart below shows aggregate latency while ingestion continues.
ClickHouse Cloud:
- 13 ms median - 270× faster than BigQuery
- 42 ms P99 - 141× faster
- 111 ms maximum - 62.5× faster
Accumulated runtime was 10.32 seconds across the 190 four-query batches.
BigQuery:
- 3.508 s median
- 5.86 s P99
- 6.93 s maximum
Accumulated runtime was 45.86 minutes across the same 190 batches. All four aggregate queries remained in seconds while ClickHouse served them in milliseconds. BigQuery’s current-answer path includes newer rows alongside the refreshed summaries.
Across the interactive-aggregation workload, ClickHouse Cloud was 267× faster overall, with summaries maintained during inserts.
Accumulated query cost and runtime
Interactive aggregations account for most of BigQuery’s accumulated query runtime. The charts below combine both workloads and show their query costs under Capacity and On-demand pricing.
ClickHouse Cloud accumulated 58.29 seconds of query runtime and BigQuery 49.36 minutes. Normalized query cost was about $0.05 for ClickHouse, versus $4.75 Capacity or $24.80 On-demand for BigQuery.
ClickHouse Cloud served the query workload 50.8× faster overall, with 94× lower normalized query cost than BigQuery Capacity, and 491× lower than On-demand.
From the field: METRO Markets and Fountain
METRO Markets’ adoption of ClickHouse Cloud shows the production benefits of faster queries and more predictable costs for real-time analytics. The team chose ClickHouse after testing it alongside BigQuery and Snowflake against its production queries. ClickHouse ran faster on both large and small queries, with one query improving from four seconds to under 200 milliseconds. It now powers near-real-time seller dashboards and company-wide analytics, while giving the team more predictable costs. Read METRO Markets’ story.
Fountain’s move from a batch analytics stack that included BigQuery to ClickHouse Cloud shows the production benefits of fresher data and faster queries for real-time applications. It now uses ClickPipes and ClickHouse Cloud to power its frontline hiring platform, Cue. Data refresh delays fell from three hours to under two minutes, most queries now return in under a second, and the company reports roughly 66% lower platform costs. Incremental materialized views prepare incoming data as it arrives, reducing the work needed at query time. Read Fountain’s story.
CostBench evaluates that efficiency across the complete analytics path, from preparing incoming data to serving queries.
BigQuery can’t match ClickHouse Cloud for real-time analytics
While fresh data kept arriving, ClickHouse Cloud led in all three measured components:
① Preparation cost: 8.5× lower than BigQuery Capacity / 9.2× lower than On-demand.
② Normalized query cost: 94× lower than Capacity / 491× lower than On-demand.
③ Accumulated query runtime: 50.8× lower under either BigQuery pricing model.
The final chart brings these results together, plotting combined preparation and normalized query cost against accumulated query runtime as fresh data arrives.
Up is lower total modeled cost; right is lower accumulated query runtime.
ClickHouse Cloud delivered 438× better end-to-end performance per dollar than BigQuery Capacity, and 512× better than On-demand, while continuously ingesting data and serving current answers.
The difference starts before a query arrives. ClickHouse orders raw data and builds current summaries during inserts. BigQuery makes new rows queryable while clustering and MV refresh continue in the background; its aggregate queries include the rows refresh has not yet summarized.
That is why BigQuery can’t match ClickHouse Cloud for real-time analytics.
