ClickHouse's pg_clickhouse v0.10 cuts TPC-H Q17 runtime 884x

Why it matters

ClickHouse is using pg_clickhouse to make its analytical engine adoptable without a wholesale PostgreSQL migration. The 884x Q17 result shows the payoff when pushdown works, while the remaining query gaps define the engineering risk.

ClickHouse engineer Josh Ventura released pg_clickhouse v0.10.0 on August 11, pushing more PostgreSQL subqueries into ClickHouse and cutting one vendor-tested TPC-H query from 32.7 seconds to 37 milliseconds.

The release advances the architecture ClickHouse co-founder and CTO Alexey Milovidov started building in 2009: keep analytical queries interactive as the underlying data grows. The underlying ClickHouse system entered production at Yandex.Metrica in 2012 and became an open-source project in 2016. Co-founders Aaron Katz and Yury Izrailevsky later helped turn that database into an independent business, and pg_clickhouse extends the same performance bet into PostgreSQL rather than asking developers to abandon the interface their applications already use.

In an engineering post announcing v0.10.0, Ventura described the release's immediate target as complete query pushdown across the 22-query TPC-H benchmark. The project moved from 12 fully pushed-down queries to 16, leaving six unresolved.

The result is narrower than the "1000x faster" shorthand suggests. ClickHouse measured an approximately 884x improvement for TPC-H Q17, a specific correlated-subquery workload at scale factor 1. The figures are vendor benchmarks, and they do not establish that PostgreSQL workloads generally become hundreds of times faster after installing the extension.

They do show why execution placement matters.

Moving the work instead of the rows

pg_clickhouse is an open-source PostgreSQL extension and foreign-data wrapper. It lets a PostgreSQL session query tables held in ClickHouse while attempting to send filters, joins, aggregates and other supported operations to ClickHouse for remote execution.

Before v0.10.0, certain correlated subqueries remained as local PostgreSQL plans. pg_clickhouse could end up retrieving rows from ClickHouse and evaluating the subquery against each outer row. That design erased the advantage of putting the analytical data in a column-oriented database because the extension moved large result sets across the database boundary and repeated work inside PostgreSQL.

Ventura's team changed the planner and deparser so supported PostgreSQL subqueries become ClickHouse subqueries inside the remote SQL statement. Ventura summarized the change plainly: "Now, subqueries in Postgres become subqueries in ClickHouse."

Q17 provides the clearest example. The query calculates an average quantity for each part through a correlated subquery over 6 million line items. ClickHouse reported that pg_clickhouse v0.3 took 32,709 milliseconds because the operation was evaluated locally. Version 0.10 completed it in 37 milliseconds after sending the full query to ClickHouse. Native PostgreSQL took 2,107 milliseconds in the same published test.

The project's current benchmark table says the tests used TPC-H scale factor 1 on a MacBook Pro with an M4 Max processor and 36 GB of memory. Q2 fell from 3,446 milliseconds in pg_clickhouse v0.3 to 24 milliseconds in v0.10. Q22 dropped from 1,415 milliseconds to 45 milliseconds, although Q22 still uses multiple remote scans rather than one foreign scan.

Those qualifications matter. TPC-H is a controlled decision-support benchmark, and the published numbers cover one machine, one data scale and selected query plans. ClickHouse has not published pg_clickhouse deployment counts, production customer results or revenue attributable to the extension.

Query correctness became the harder problem

Sending SQL to another database engine creates a second obligation: the remote query must return the result PostgreSQL would have produced.

Ventura focused part of the release on IN, NOT IN, ANY and ALL expressions involving null values. PostgreSQL uses three-valued logic, where an expression can evaluate to true, false or null. ClickHouse's default behavior for these operations uses two-valued logic. A naive translation can therefore return rows PostgreSQL would have filtered out.

Version 0.10 adds guards based on how an expression is consumed and whether pg_clickhouse can prove its operands cannot be null. That approach reduces the risk of an apparently successful query producing a subtly different answer.

The new correlated-subquery path requires ClickHouse 25.8 or later. pg_clickhouse checks the server version during planning and falls back to local evaluation when the connected ClickHouse server cannot handle the translated query.

Six TPC-H queries remain outside full pushdown: Q13, Q15, Q16, Q18, Q20 and Q21. Several are blocked because PostgreSQL converts their subqueries into anti- or semi-joins whose inputs contain additional joins. The pg_clickhouse deparser cannot yet traverse join trees on both sides of that operation. ClickHouse identifies that planner work as the next major step.

The extension is becoming part of ClickHouse's Postgres strategy

ClickHouse introduced pg_clickhouse in December 2025 to reduce the application work required when analytical data moves out of PostgreSQL. The premise was that moving data through replication had become easier, while rewriting years of SQL embedded in dashboards, object-relational mappers and scheduled jobs remained expensive.

The extension has since become a component of Postgres managed by ClickHouse, which entered public beta in May 2026. That service combines PostgreSQL for transactions, change-data capture into ClickHouse and pg_clickhouse as a query layer spanning both systems. The strategic value lies in preserving PostgreSQL as the application-facing interface while ClickHouse captures the heavier analytical execution.

The strategy targets accounts that already depend on PostgreSQL and would resist a full database migration. It also puts pressure on the engineering team to support the long tail of PostgreSQL query behavior, where compatibility failures can be harder to detect than outright errors.

ClickHouse has the capital to keep working through that list. In January, ClickHouse raised a $400 million Series D led by Dragoneer Investment Group, with participation from Bessemer Venture Partners, GIC, Index Ventures, Khosla Ventures, Lightspeed Venture Partners, T. Rowe Price-advised accounts and WCM Investment Management. ClickHouse said in May that it had passed 4,000 customers and $250 million in annual run-rate revenue.

Version 0.10 also rebuilds the binary driver around ClickHouse's plain-C client library, streams large results in blocks, adds compression and TLS controls, and gives concurrent foreign scans separate connections. The latter change addresses concurrency bugs in the driver. ClickHouse also expanded pushdown support for statistical aggregates, ordered-set aggregates, partitionwise aggregation, date operations and string functions.

The benchmark improvement will attract attention, but pg_clickhouse's larger test is compatibility. Milovidov built ClickHouse around fast analytical execution. The company is now betting that ClickHouse can sell that engine behind the PostgreSQL interface developers already trust. Ventura's subquery work closes several of the most expensive gaps, with six benchmark queries and a much larger universe of production SQL still ahead.