ClickHouse vs BigQuery: Serving or Serverless? (2026)

Quick verdict

Short answer

Choose BigQuery when you are on Google Cloud and want analytics with nothing to provision: you load data, run SQL and pay per TiB scanned or for slot capacity, with a free tier to start. Choose ClickHouse when you need to serve many fast queries over continuously arriving data (product analytics, observability, customer-facing dashboards), when per-query scan pricing would penalise a steady query load, or when you want an open source engine that runs on any cloud or on your own servers. The two are often combined, with BigQuery as the warehouse and ClickHouse for serving.

How we know: This comparison is research-based: architecture, pricing models, free tiers, constraints, transactions and Iceberg support were checked against ClickHouse's and Google Cloud's official documentation and pricing pages in October 2026. We have not run benchmarks, so no performance figures are given.

ClickHouse describes itself as a real-time analytics database management system. It stores data by column in MergeTree tables designed for high ingest rates and is open source under the Apache License 2.0. You can self-host it or use ClickHouse Cloud (Basic, Scale and Enterprise plans on AWS, GCP and Azure, plus Bring Your Own Cloud). The latest release in the ClickHouse changelog is 26.9 (September 2026).

BigQuery is Google Cloud's fully managed, serverless data warehouse. Queries run on slots, which Google defines as virtual compute units, but you never manage servers: you choose between on-demand pricing (pay for the bytes each query processes) and capacity pricing through BigQuery editions (Standard, Enterprise and Enterprise Plus), billed per slot-hour. BigQuery runs only on Google Cloud, and it is proprietary.

For the wider question of when an analytical system is needed at all, see Data Warehouse vs Database.

Side by side

Aspect	ClickHouse	BigQuery
Product type	Open source columnar database; self-hosted or managed (ClickHouse Cloud)	Proprietary serverless data warehouse, Google Cloud only
What you manage	Servers and cluster when self-hosted; a service size and scaling settings in ClickHouse Cloud	Datasets, tables and optionally slot reservations; no servers
Billing unit	Free to self-host; Cloud bills compute unit-hours and storage per TB-month	On-demand per TiB processed, or editions per slot-hour; storage per GiB-month (logical or physical)
Free tier	30-day ClickHouse Cloud trial with USD 300 in credits; open source is free	First 1 TiB of query processing and first 10 GiB of storage free each month; BigQuery sandbox without a credit card
Streaming ingestion	Continuous inserts into MergeTree; ClickPipes in Cloud for Kafka, Kinesis, object storage and Postgres/MySQL CDC	BigQuery Storage Write API for high-throughput streaming
Pre-aggregation	Incremental materialized views run at insert time	Materialized views
Keys and constraints	Primary key defines sort order and sparse index; uniqueness not enforced	Primary and foreign keys can be declared but are not enforced
Updates and transactions	Lightweight DELETE; lightweight UPDATE in beta; multi-statement transactions experimental and not supported in Cloud	GoogleSQL DML (UPDATE, DELETE, MERGE); multi-statement transactions with snapshot isolation
Apache Iceberg	Iceberg table engine (read; insert with documented limits) and lakehouse catalogs including BigLake Metastore	Apache Iceberg managed tables (GA) in customer-owned Cloud Storage, with DML, streaming and Iceberg snapshots for other engines
Main trade-off	You size and design for the workload: sort keys, inserts, denormalised tables	On-demand cost grows with bytes scanned; steady high query volumes usually need capacity planning

Key differences

Serverless scans versus a provisioned engine

BigQuery's defining trait is that there is nothing to size. Each query is allocated slots by the service; on the on-demand model Google says you will generally have access to up to 2,000 concurrent slots, shared among all queries in a project, with occasional temporary bursts above that and fewer slots when capacity in a location is contended. This suits ad hoc analysis, scheduled batch jobs and teams that want SQL over large datasets without operating anything.

ClickHouse runs on servers you provision, or on a ClickHouse Cloud service with a chosen size. ClickHouse Cloud's Scale and Enterprise plans add vertical autoscaling, automatic idling and Warehouses (separate compute services sharing the same data); the Basic plan is a fixed-size single replica. In return for that sizing work, ClickHouse is designed to keep latency low for many repeated queries over fresh data, using a sparse primary index on the sort key and incremental materialized views that compute aggregates as data arrives.

Pricing models and what they reward

BigQuery on-demand pricing charges for the bytes each query processes, so cost follows how much data your queries scan, not how long anything runs. Partitioning and clustering reduce bytes scanned, and selecting only the columns you need matters because storage is columnar. For predictable spend, BigQuery editions bill slot-hours instead, with autoscaling reservations (one-minute minimum by default) and, for Enterprise and Enterprise Plus, one-year and three-year commitments that Google lists at 20% and 40% discounts.

ClickHouse Cloud bills compute unit-hours and storage, regardless of how many bytes each query scans; self-hosted ClickHouse costs whatever your infrastructure costs. In our view, a dashboard or API that runs the same queries thousands of times a day tends to favour a provisioned engine, while occasional large analyses favour pay-per-scan. That is a pattern, not a rule: estimate both with your own query volumes.

-- BigQuery (GoogleSQL): partition and cluster to cut bytes scanned
CREATE TABLE analytics.events (
  ts         TIMESTAMP,
  user_id    INT64,
  event_type STRING,
  value      FLOAT64
)
PARTITION BY DATE(ts)
CLUSTER BY event_type, user_id;

-- ClickHouse: partition and sort key on a MergeTree table
CREATE TABLE events (
  ts         DateTime,
  user_id    UInt64,
  event_type LowCardinality(String),
  value      Float64
) ENGINE = MergeTree
PARTITION BY toYYYYMM(ts)
ORDER BY (event_type, user_id, ts);

Data changes and consistency

BigQuery supports GoogleSQL DML (INSERT, UPDATE, DELETE, MERGE) and multi-statement transactions that use snapshot isolation, contained in one query or spanning queries in a session. Google documents limits, including up to 100 tables mutated per transaction and no DDL on permanent entities inside one. Primary and foreign keys can be declared but, in Google's words, BigQuery does not enforce them.

ClickHouse also leaves uniqueness unenforced, and its change model is different: lightweight DELETE, a lightweight UPDATE documented as beta and intended for small shares of a table, heavier ALTER TABLE ... UPDATE mutations, and engines such as ReplacingMergeTree that model changes as inserts. Multi-statement transactions are experimental and not supported in ClickHouse Cloud. For pipelines that rely on frequent MERGE operations, BigQuery is the simpler choice. See ClickHouse vs PostgreSQL for more on ClickHouse's update model.

Cloud reach and open formats

BigQuery runs on Google Cloud. Its Apache Iceberg managed tables (formerly called BigLake tables for Apache Iceberg in BigQuery) are generally available: they store data in your own Cloud Storage buckets, support GoogleSQL DML and streaming through the Storage Write API, and export Iceberg snapshots so engines such as Spark can read them.

ClickHouse runs anywhere: on your own hardware, in any cloud, or as ClickHouse Cloud on AWS, GCP or Azure. It documents an Iceberg table engine (reads, and inserts with type limitations) and a DataLakeCatalog engine that connects to catalogs including BigLake Metastore, AWS Glue, Databricks Unity Catalog and Iceberg REST, plus support for Delta Lake, Hudi and Paimon. ClickHouse also publishes a guide comparing ClickHouse Cloud with BigQuery for migrations, which maps BigQuery projects to ClickHouse Cloud services and datasets to databases.

Pricing and licensing

BigQuery on-demand query pricing on cloud.google.com/bigquery/pricing in October 2026, for regions including Iowa (us-central1), is USD 6.25 per TiB processed after the first 1 TiB per month, which is free. Storage is billed per GiB per month (active and long-term, logical or physical), with the first 10 GiB free each month. Capacity pricing through the Standard, Enterprise and Enterprise Plus editions is billed per slot-hour, with commitment discounts on Enterprise and Enterprise Plus. Streaming, data transfer and other services are billed separately. The BigQuery sandbox lets you use the free tier without a credit card.

ClickHouse open source is free under the Apache License 2.0. ClickHouse Cloud is pay-as-you-go for compute (per compute unit-hour) and storage (per TB-month), varying by plan, cloud provider and region. As one example, clickhouse.com/pricing lists the Enterprise plan on AWS US East 1 at USD 0.39030 per compute unit-hour and USD 25.30 per TB per month of storage (October 2026). New accounts get a 30-day trial with USD 300 in credits and no credit card.

The units are not directly comparable. Use Google's pricing calculator and ClickHouse's calculator with your own data volumes and query counts.

Pricing checked on the vendors' official pages on 7 October 2026. Prices change; confirm before buying.

Where each one leads

ClickHouse strengths

Designed for low-latency queries over continuously ingested, mostly append-only data
Compute billed by time, not bytes scanned, which can suit steady, repetitive query loads
Apache 2.0 licence: runs on any cloud, on premises, or as ClickHouse Cloud or BYOC
Incremental materialized views and specialised analytics SQL such as ASOF JOIN

BigQuery strengths

Serverless: no clusters, nodes or services to size
Monthly free tier (1 TiB of queries, 10 GiB of storage) and a sandbox without a credit card
GoogleSQL DML with multi-statement transactions using snapshot isolation
Two pricing models: pay per TiB processed, or slot-hour capacity through editions
Iceberg managed tables (GA) in customer-owned storage, readable by other engines

Limitations

ClickHouse limitations

Primary keys do not enforce uniqueness; duplicates need engine or design choices
Lightweight UPDATE is beta; multi-statement transactions are experimental and not supported in ClickHouse Cloud
Someone must size the service or cluster; self-hosting adds replication, upgrades and backups
Iceberg support has documented limitations, including unsupported types on insert

BigQuery limitations

Google Cloud only; no self-hosted option
On-demand costs scale with bytes scanned, so frequent queries over large tables need partitioning, clustering or capacity pricing
Primary and foreign keys are declared but not enforced
Transactions have documented limits, such as up to 100 tables mutated per transaction

When to choose each

Choose ClickHouse if

You serve analytics to an application, API or many dashboard users, with steady query volumes
Data arrives continuously as events, logs or metrics and must be queryable quickly
You run on AWS, Azure, on premises or several clouds, or want to self-host
You want an open source engine with a managed option rather than a single-cloud service

Choose BigQuery if

Your data and teams are already on Google Cloud
You want serverless SQL with no capacity planning for ad hoc and batch analysis
Query volume is irregular, so paying per TiB processed (with a free monthly TiB) fits
Your ELT relies on MERGE, UPDATE and multi-statement transactions

When neither is right

Your data fits on one machine or lives in local files: an embedded engine may be enough; see DuckDB vs Snowflake.
You want a managed warehouse that runs on several clouds: compare Snowflake vs BigQuery and ClickHouse vs Snowflake.
Your work centres on Spark, notebooks and machine learning over a lakehouse: see ClickHouse vs Databricks.
Your analytics are modest and your data already sits in an OLTP database: see ClickHouse vs PostgreSQL and ClickHouse vs MySQL.

Final recommendation

Bottom line

BigQuery is the natural default on Google Cloud when you want analytics without operating anything, especially for irregular, ad hoc and batch workloads where paying per TiB processed (or for slot capacity) is simple to reason about. ClickHouse is the stronger fit for serving fast, repeated queries over fresh event data, for multi-cloud or self-hosted deployments, and when you prefer an open source engine. Because ClickHouse can connect to BigLake Metastore and both work with Iceberg, using BigQuery as the warehouse and ClickHouse as a serving layer is a practical pattern. For other options, see the best BigQuery alternatives.

Frequently asked questions

Is ClickHouse cheaper than BigQuery?

It depends on the workload, and we have not measured it. BigQuery on-demand charges per TiB processed (USD 6.25 per TiB in regions such as us-central1 in October 2026, after a free 1 TiB per month), so cost follows bytes scanned. ClickHouse Cloud charges for compute time and storage. Many repeated queries over the same large tables tend to favour time-based billing; occasional queries favour per-scan billing. Model your own query volumes with both calculators.

Is BigQuery serverless?

Yes. You do not provision servers or clusters. Queries run on slots managed by Google; you can pay on demand per TiB processed or buy slot capacity through the Standard, Enterprise and Enterprise Plus editions.

Can ClickHouse run on Google Cloud?

Yes. ClickHouse Cloud is available on GCP as well as AWS and Azure, and you can also self-host open source ClickHouse on Google Compute Engine or Kubernetes. ClickHouse documents a connection to BigLake Metastore for querying lakehouse tables.

Does BigQuery enforce primary keys?

No. Google's documentation states that BigQuery does not enforce primary and foreign key constraints; you must make sure your data conforms to them. ClickHouse does not enforce uniqueness either: its primary key defines sort order and a sparse index.

How do I move data from BigQuery to ClickHouse?

ClickHouse publishes a migration guide for BigQuery, and lists BigQuery as a ClickPipes source in private preview in October 2026. A common approach is to export tables to Parquet files in Cloud Storage and load them into ClickHouse.

Sources

Checked October 2026.

How we research comparisons: our editorial method.