ClickHouse

Editor’s note: This ClickHouse review combines hands-on SQL tests on ClickHouse’s public demo with an assessment of its documented Cloud features and pricing.

Quick verdict: I recommend ClickHouse for engineering teams building dashboards, event analytics, and applications that need fresh analytical data. Its columnar SQL engine impressed me in a small public-demo test, but getting reliable results and predictable costs still takes database expertise.

Key Takeaways

• My public-demo annual aggregation read 31.6 million rows in approximately 45 to 47 milliseconds of server execution time.
• You can self-host the open-source database or pay for managed ClickHouse Cloud.
• ClickPipes offers managed ingestion, including generally available PostgreSQL and MySQL change data capture.
• Cloud compute rates are only part of the bill; allow for ingestion, storage, and backups.
• Sorting keys and update behavior need engineering attention, and a public-demo result cannot predict production latency.

In this review, I’ll take a closer look at my query results, the Cloud costs I’d budget for, and where I’d choose Snowflake, BigQuery, or DuckDB instead.

ClickHouse Pros and Cons

How Much Does ClickHouse Cost?

ClickHouse Cloud charges by usage, so I would budget from resource requirements rather than treat its advertised monthly starting figures as subscriptions. The following compute rates apply to AWS Northern Virginia; other regions and providers can differ.

• Basic ($0.2181 per compute-unit-hour): for smaller evaluations and workloads that fit a fixed service.
• Scale ($0.2985 per compute-unit-hour): my starting point for production teams needing resource flexibility.
• Enterprise ($0.3903 per compute-unit-hour): for organizations with additional identity, encryption, and upgrade-control requirements.
• Self-hosted ($0 software license cost): for teams willing to run the infrastructure themselves.

Option	Compute billing	Main consideration
Basic	Active compute-unit-hours	One fixed 8 or 12 GiB replica; no vertical or horizontal scaling
Scale	Active compute-unit-hours	Configurable resources, private networking, and compute separation
Enterprise	Active compute-unit-hours	Adds SAML SSO, customer-managed keys, and scheduled upgrades
Self-hosted	Your infrastructure costs	You own deployment and ongoing operations

One standard compute unit represents 8 GiB of RAM and two vCPUs. Count the units across every replica: three replicas with 16 GiB each use six units while running. Quiet periods between queries do not make an active service free.

For a concrete example, one Basic unit running for 730 hours costs approximately $159.21 in compute. Two Scale units over the same period cost $435.81. These are calculated examples, not inclusive plan prices or performance recommendations.

Database compute is metered per minute. Cloud storage is listed at $25.30 per TB per month in this region. Stored compressed data and retained backups incur charges, and ingestion and data transfer can add more. I would measure compression with representative data before using it to justify a low storage estimate.

New Cloud organizations receive $300 in trial credits for up to 30 days. The trial ends when either limit is reached.

Is ClickHouse Good Value for Money?

I like the choice between managed Cloud and self-hosting, but your query pattern matters more than the headline rate:

• Frequent application queries: paying for running compute may make sense when the service stays busy.
• Occasional analysis: compare the full monthly cost with BigQuery’s on-demand model or local DuckDB.
• A small operations team: Cloud can save infrastructure work, even when self-hosted software is free.

Reviewer’s Notes: I’d use Basic for a modest evaluation and price a Scale deployment before committing a production application. Choose Enterprise when its specific controls meet a requirement; a higher tier alone does not establish value.

My Experience With ClickHouse

I tested ClickHouse by sending SQL requests over HTTPS to its public demo service. This gave me direct access to query results and execution statistics on an existing dataset, without creating a paid Cloud service.

Inspecting the data before querying

I started by inspecting the schema and table definition for the UK property transaction dataset, uk.uk_price_paid. The table included sale prices, dates, postcodes, and address fields. Its sorting key began with postcode1 and postcode2, followed by address fields.

That detail gave me two useful query shapes to compare: a date-filtered annual summary and a postcode-specific calculation. I liked having the table definition available alongside the query results because it helped explain how much data each request read.

Running an annual summary

I counted transactions and calculated average prices for each year from 2020 through 2024:

SELECT toYear(date) AS year,
       count() AS sales,
       round(avg(price), 2) AS average_price
FROM uk.uk_price_paid
WHERE date >= '2020-01-01' AND date < '2025-01-01'
GROUP BY year
ORDER BY year
SETTINGS use_query_cache = 0;

Both runs returned the same five annual results. The 2024 row contained 931,453 transactions and an average price of £400,201.71 within this dataset.

The server reported reading 31,610,742 rows in approximately 45 and 47 milliseconds. Total request time, including the network round trip, was approximately 300 milliseconds on each run. That difference matters if you are sizing an application around a database execution figure.

Filtering by postcode and calculating a running total

My postcode query counted sales for SW1A and calculated their average price. It returned 541 transactions while reading only 40,960 rows, a much smaller read than the annual query.

Surprisingly, this narrower query took longer: approximately 108 to 122 milliseconds on the server. The public service’s hardware, storage caches, and concurrent load were outside my control, so I would not assign a cause. It was a useful reminder that fewer rows read does not guarantee a faster individual request.

Test	Rows read	Server execution	Total request time
Annual summary, two runs	31,610,742 each	45 to 47 ms	298 to 300 ms
SW1A postcode filter, two runs	40,960 each	108 to 122 ms	362 to 382 ms
Cumulative annual sales	31,610,742	66 ms	342 ms

I also used a SQL window function to calculate cumulative annual sales. It returned a final total of 5,050,121, consistent with adding the five annual transaction counts. I could build the summary and cumulative calculation entirely in SQL.

Author’s Testing Notes: The aggregation performance impressed me, but these were five analytical query executions on a shared public service. I disabled the query result cache; I did not control other caches or concurrent users. Treat these figures as observed demo results, not a production benchmark.

Query Design Matters More Than the Demo Speed

ClickHouse rewards deliberate table design. In my tests, the postcode filter matched the beginning of the table’s sorting key and read dramatically fewer rows than the date-filtered summary. That is a practical reason to understand your common filters before loading a large dataset.

I would start with the queries your application actually needs. A schema optimized for postcode lookups may make a different trade-off from one designed around account IDs or event dates. Also, a ClickHouse primary key does not enforce unique rows, so importing familiar relational assumptions can create correctness problems.

Incremental materialized views can calculate aggregates as new blocks arrive and write the results into a target table. I like this for repeated dashboard metrics because it moves some calculation work to ingestion. However, existing data needs a backfill, and later source updates or deletes do not automatically correct those stored aggregates.

Updates are supported, including lightweight updates that store changed values in patch parts. They still add work, and broad changes can need a different approach. I would evaluate both correction behavior and read performance before choosing ClickHouse for data that changes frequently.

For a team already serving reports from Snowflake, I would want a specific reason to add another database, such as a demanding application query workload. A quick aggregate alone would not justify moving well-functioning reporting pipelines.

ClickPipes Makes Ingestion Easier, but Adds a Bill

ClickPipes can manage one-time imports and continuous ingestion into ClickHouse Cloud. PostgreSQL and MySQL change data capture, or CDC, are generally available; MongoDB CDC is in public beta. I would check the maturity of your actual connector rather than assume every listed source has the same support status.

The appeal is straightforward: you can keep application data in PostgreSQL and send changes to a database dedicated to analytics. I like that division of responsibilities more than trying to make the analytical engine replace transactional storage.

CDC pricing has two parts:

• Data ingestion: $0.10 per GB for initial loads or resyncs and $0.20 per GB for ongoing changes, measured before compression.
• Shared connector compute: defaults to $0.10 per hour per Basic service or $0.20 per hour per Scale or Enterprise service, with larger allocations costing more.

Streaming ClickPipes use a different model: $0.20 per compute-unit-hour plus $0.04 per GB ingested. I would keep those connector charges separate from database compute in a cost estimate.

My main concern is correctness during change. A useful evaluation should cover updates and deletions alongside fresh inserts, and measure how quickly those changes appear in your reports. Managed ingestion reduces pipeline administration, but it does not decide what your application should display while data is catching up.

Cloud Operations and AI Features

Cloud’s strongest operational feature for me is compute separation. Multiple services can query shared table storage, giving a dashboard and an analyst workload their own service endpoints without duplicating the dataset.

That is useful when an exploratory query should not compete directly with customer-facing analytics. Still, read-write services can share background work; I would not describe them as perfectly isolated. Read-only services avoid merge work and deserve consideration for serving queries.

Scale and Enterprise support flexible resources, with vertical autoscaling on standard profiles. Scaling also needs realistic expectations: new replicas need resources and warm caches, so adding capacity does not instantly guarantee application latency. Snowflake’s separately sized virtual warehouses deserve a comparison if workload separation is your main requirement.

ClickHouse also includes documented AI capabilities:

• ClickHouse Assistant: generates SQL, visualizations, and summaries using service context, with separate documentation assistance. Your organization must enable AI features and accept the data-handling consent.
• Vector search: supports exact distance queries and approximate HNSW indexes, allowing embeddings and analytical columns to live together.

I like the convenience of asking questions in natural language, but an assistant-generated query still needs someone who understands the data. Generated schemas also deserve review: stacking incremental views can add ingestion work and confusing dependencies.

HNSW introduces its own trade-off. The index needs memory, and approximate search exchanges some recall for speed. I would choose ClickHouse for vectors when combining retrieval with SQL analytics is valuable, rather than assuming this feature alone makes it the best database for every AI application.

How Does ClickHouse Compare With Alternatives?

• Snowflake: worth prioritizing when separate virtual warehouses and an established reporting setup already meet your needs. Warehouse credits depend on size and running time, with a 60-second minimum when starting or resuming. Compare equivalent concurrency and availability requirements before accepting a claim that ClickHouse costs less.
• BigQuery: appealing for intermittent analysis where on-demand scan billing suits your usage, or teams that prefer its capacity pricing option. The first 1 TiB of monthly on-demand query processing is free. Repeated large scans can change the economics; estimated bytes and maximum bytes billed help control that risk. Adding LIMIT to an unclustered-table query does not necessarily reduce bytes scanned.
• DuckDB: my first stop for local SQL analysis when a managed database service would add unnecessary administration. Its embedded engine runs inside your process. That operating model differs from ClickHouse’s shared database service, so start with where the analysis runs and who needs access before comparing query timings.

ClickHouse earns its place when you need an analytical database behind an application and have engineers who can own schema design and performance. I would compare all candidates using your data, recurring queries, and expected concurrent users.

How We Tested ClickHouse

We inspected the public demo’s schema and table definition, then ran five analytical queries: two annual summaries, two postcode filters, and one cumulative window calculation. The service reported version 26.10.1.39301 on October 5, 2026.

I recorded both server statistics and total request times, checked repeated results, and compared the cumulative total with the annual counts. Cloud administration, ingestion, and AI feature assessments describe documented capabilities; the hands-on findings cover SQL execution on the public dataset.

Prices are current as of October 2026. Cost examples use stated resources and active hours, not measured invoices.

Should You Choose ClickHouse?

Choose ClickHouse if you need fresh analytical data behind an application and have someone who can own the database design. My tests showed responsive aggregation across millions of rows, and the combination of managed ingestion and separate query services gives it a useful production path.

The harder buying decision is whether you need another analytical system. I would keep a transactional database for application records, use DuckDB for suitable local work, and keep an existing warehouse when it already serves your reporting needs well.

Start with a representative dataset and a small set of important queries. Measure correctness, concurrent performance, and the complete monthly bill before committing.

ClickHouse FAQ

Is ClickHouse free?

The open-source database is free to download. Self-hosting still costs infrastructure and staff time. ClickHouse Cloud is usage-billed after its limited trial, so do not budget as though it has a permanent free service tier.

Can ClickHouse replace PostgreSQL?

It can take over analytical queries, but I would generally keep PostgreSQL for transactional application data. Multi-statement transactions in the core ClickHouse engine remain experimental. CDC lets the two systems serve different jobs.

Does ClickHouse support updates and deletes?

Yes. Avoid choosing or rejecting it on the outdated assumption that data cannot change. Evaluate the update strategy and downstream materialized views, because changes can add processing work and require deliberate correction logic.

Do I need SQL to use ClickHouse?

SQL skills are valuable even with ClickHouse Assistant. Natural-language help can generate queries, but you still need to judge whether the joins, filters, and calculations answer the right question.

Is ClickHouse cheaper than Snowflake or BigQuery?

It depends on utilization and workload. Compare total compute, storage, ingestion, and operational costs under equivalent requirements. My public-demo query timings do not establish a price advantage over either warehouse.