--- title: "ClickHouse Is Fast. Your Pipeline Isn't." published: 2026-04-14T14:15:43.000-04:00 updated: 2026-04-14T14:15:43.000-04:00 excerpt: "ClickHouse is fast. But the pipeline tax, ACID trade-offs, and two-system overhead are part of the decision too. Here's the full picture." tags: performance authors: Matty Stratton --- > **TimescaleDB is now Tiger Data.** ClickHouse is fast. The benchmarks aren't lying. If you've [run a comparison against vanilla Postgres](https://www.tigerdata.com/blog/what-is-clickhouse-how-does-it-compare-to-postgresql-and-timescaledb-and-how-does-it-perform-for-time-series-data) on the same dataset, the results aren't close. ClickHouse wins by 10x-100x on typical analytical patterns. That benchmark is also only measuring one dimension of your decision. It tells you how fast queries run on static data. It doesn't tell you anything about data freshness, transactional correctness, pipeline reliability, or the operational cost of keeping two systems synchronized. This post isn't about whether ClickHouse is fast. It's about the full cost of getting your data there, and keeping it correct once it arrives. ## What ClickHouse is actually good at ClickHouse is a columnar OLAP database built for analytical scan performance. It's great at aggregations over large datasets, column-oriented scans that skip irrelevant data, compression that keeps big datasets resident in memory, and query parallelism across cores. For batch analytics on historical data where "fresh" means "reflects the last ETL run," ClickHouse is a solid choice. Data warehousing, offline reporting, retrospective analysis. These are real ClickHouse strengths and I'm not going to pretend otherwise. The question you need to answer for yourself is whether your use case is actually batch analytics, or whether it's operational analytics that needs to be fresh and correct. ## The pipeline tax Here's the thing about ClickHouse: your data doesn't teleport there from Postgres. You need a pipeline. You've got options. [CDC via Debezium](https://www.tigerdata.com/blog/implementation-of-change-data-capture-using-timescaledb-for-shoplogix-industrial-monitoring-services), scheduled ETL jobs, Kafka-based streaming, application-level dual-writes. Each one introduces costs that won't show up in any benchmark you've read. **Lag.** There's always a gap between a row being committed in Postgres and being queryable in ClickHouse. CDC pipelines typically add 5-30 seconds. Batch ETL adds minutes to hours. Dual-writes add milliseconds, but now you've got a consistency problem: when one write succeeds and the other fails, your two systems are telling different stories about what's true. **Drift.** Every schema change in Postgres needs to propagate to ClickHouse. Column additions, type changes, table restructuring: all of it requires pipeline updates. Every migration is now a coordinated change across two systems. Good luck. **Failure modes.** Pipelines break. Kafka consumers fall behind. CDC slots get dropped. Backfills happen after outages. Each of these failure modes needs its own monitoring, alerting, and runbook. All of this overhead exists purely because your data lives in two places. **Correctness gaps.** ClickHouse uses eventual consistency. Rows arrive out of order. Late-arriving data might not appear in already-computed aggregations. Deduplication requires explicit schema decisions (ReplacingMergeTree and friends). When a dashboard query runs during a pipeline hiccup, the results are wrong, with no transaction isolation to tell you that. ## What you actually lose without ACID Let’s be specific about the [ACID](https://www.tigerdata.com/learn/understanding-acid-compliance) trade-off, because it matters more in practice than it sounds in theory. ClickHouse doesn't support multi-row transactions. A batch INSERT either succeeds or fails as a batch, but you can't roll back a logical transaction that spans multiple inserts across tables. If your analytics join orders, payments, and inventory, the lack of transactional consistency means your results can reflect different points in time. (Whether that matters depends on your use case, but you should know it before you commit to the architecture.) Updates work differently than you expect. ClickHouse mutations are background operations. When source data gets corrected in Postgres (a sensor recalibration, a price adjustment, a retroactive fix), getting that correction into ClickHouse means re-ingesting the affected data or running an async mutation that finishes whenever the system gets around to it. In Postgres, a corrected value is immediately correct. In ClickHouse, it's eventually correct. There are no foreign keys, constraints, or triggers. Data integrity is your pipeline's problem now. If bad data gets through, ClickHouse will store it faithfully. Garbage in, garbage queryable. ## The real cost: operating two systems Two databases means two sets of _everything_. Monitoring dashboards, alerting rules, and backup strategies. Capacity planning, version upgrade procedures, and security patching schedules. You also need two mental models. When a dashboard shows unexpected numbers, the engineer debugging it has to figure out: is the data wrong in Postgres, or is it right in Postgres but stale in ClickHouse? Is the pipeline behind? Did a schema change not propagate? Is deduplication working correctly? So many questions. And the pipeline itself is a third system with its own maintenance burden. Kafka clusters, CDC connectors, ETL orchestrators. None of these are zero-maintenance infrastructure. Total cost of ownership isn't "Postgres cost + ClickHouse cost." It's Postgres cost plus ClickHouse cost plus pipeline cost plus coordination overhead plus the debugging time you spend every time the two systems disagree. That last one is harder to budget for. ## When the split is actually worth it Here's a useful test before we go further. Have your stakeholders ever asked "why is the dashboard showing old data?" If yes, you have a freshness requirement. If the answer to that question has ever been "because the pipeline was behind," then a faster query engine isn't going to solve your problem. I want to be honest here, because this is where a lot of competitive posts fall apart. There are legitimate reasons to run ClickHouse alongside Postgres. The split makes sense if your analytics are batch-oriented and hours of lag is acceptable. If your queries are read-only historical scans and you already have Kafka running for other reasons. If analytical query volume would overwhelm your operational database. It doesn't make sense if your stakeholders want to see current data. If a correction in Postgres needs to show up immediately in your dashboards. If the only reason you'd build a pipeline is to feed ClickHouse. Or if your team is small enough that the operational burden of running three systems isn't worth the query speed gain. ## The alternative [TimescaleDB](https://www.tigerdata.com/timescaledb) extends Postgres so analytical queries perform well on the same data, in the same database, with the same transactional guarantees. Hypertables with [columnar compression](https://www.tigerdata.com/blog/building-columnar-compression-in-a-row-oriented-database) give you analytical scan performance on time-series data without moving it anywhere. [Continuous aggregates](https://www.tigerdata.com/learn/olap-workloads-on-postgresql-a-guide) pre-compute common rollups incrementally, so dashboards stay fast without batch jobs. FlightAware dropped a 6.4-second query to 30 milliseconds using continuous aggregates alone, without changing their data model or moving to a separate system. Real-time aggregates layer the newest raw data on top of those precomputed rollups in a single query, so results stay current without waiting for a refresh cycle. Your data is always fresh because nothing moved it. Corrections are immediate because there's no second system to propagate them to. And there's no pipeline paging you at 3am, because there's no pipeline. > "TimescaleDB strikes a phenomenal balance between the simplicity of storing your analytical data under the same roof as your configuration data, while also gaining much of the impressive performance of a specialized OLAP system." — Robert Cepa, Senior Software Engineer, Cloudflare ([How TimescaleDB helped Cloudflare scale analytics — and why they chose it over ClickHouse](https://www.tigerdata.com/blog/how-timescaledb-helped-us-scale-analytics-and-reporting)) Worth being straight with you: for pure OLAP workloads on petabyte-scale historical data, a dedicated columnar store like ClickHouse will outperform TimescaleDB on raw scan throughput. That gap is real. For batch analytics on historical data where freshness and correctness aren't the point, ClickHouse is a reasonable choice. But for most teams building operational analytics on live data, the architectural cost of moving that data doesn't justify the query speed gain. ## The thing the benchmark doesn't tell you The fastest query engine in the world doesn't help when the data it's querying is stale. And "the pipeline was behind" is a terrible answer to give your stakeholders at 2am. ClickHouse is fast. The benchmarks are real. The trade-off is also real: pipelines, lag, drift, eventual consistency, and a second system to operate forever. If your analytics can tolerate staleness and your team has the infrastructure to keep two systems in sync, ClickHouse is worth serious consideration. If your analytics need to be fresh, correct, and transactional, the architecture that gets you there matters more than the query speed of any single component. The benchmark tells you one thing. The architecture is what you'll live with. If you want to see what analytics on your live Postgres data actually looks like, [start a free Tiger Cloud database](https://console.cloud.tigerdata.com/signup). Your existing schema works as-is. No pipeline required.