pg_vexec Extension Claims to Beat ClickHouse in Benchmark Run by Its Own Creator

A month of solo work against the most-cited columnar engine on the market

Exactly one month after publishing an account of porting Greenplum's ORCA query planner to PostgreSQL 19, developer Igor Suhorukov returned to Planet PostgreSQL with a concrete result: pg_vexec, an experimental extension that adds vectorized execution to the database. According to him, the CPU version already runs faster than ClickHouse on part of ClickBench, the public benchmark used to compare columnar databases.

The announcement is neither an academic paper nor a mature product release. It's the logbook of an individual project that, in one month, went from an experimental Greenplum fork to numbers that come close to ClickHouse in its own arena. Suhorukov published the full test telemetry, a text explaining the architecture, and the CPU version's source code across three repositories.

The numbers: a comfortable lead on Parquet, a tight race on MergeTree

The tests ran in hot run mode (cache already warmed, best result out of three attempts) on an MSI Raider A18 HX A9W notebook, comparing pg_vexec against the LTS version of ClickHouse. The author used two ClickBench metrics: the shifted geometric mean (which summarizes performance across multiple queries without letting one slow query distort the total) and total execution time.

The author's own title sums up the picture well: ahead on Parquet, close on MergeTree. On ClickHouse's native engine, hand-tuned over the years for columnar ordering and compression, pg_vexec's advantage is small. When reading Parquet files, though (a format where ClickHouse isn't the sharpest tool on the market), the gap jumps to an order of magnitude.

Where the vectorization comes from: ORCA, Greenplum, and the Cloudberry fork

Traditional PostgreSQL executes queries using the Volcano model: each operator in the plan processes one tuple at a time, passing it along the execution tree. It's an elegant, flexible design, but costly in CPU cycles when data volume is large, because each tuple pays the cost of repeated function calls.

Vectorized execution tackles this problem by processing blocks of values from the same column at once, which makes better use of CPU cache and SIMD instructions. It's the principle behind ClickHouse's engine and also behind extensions already known in the Postgres ecosystem, such as pg_duckdb (which embeds DuckDB) and Citus's columnar storage. pg_vexec enters this same territory, but via a different path: instead of embedding another engine, it derives from ORCA, the cascades-style query optimizer originally written by Pivotal for Greenplum.

The CPU version's source code is split across three repositories: pg_vexec itself, pg_ch_table_engines (which reproduces ClickHouse's table engines concept inside PostgreSQL, including something equivalent to MergeTree), and a branch called extension_postgresql_19 in the Cloudberry fork, the community project that maintains Greenplum's legacy. That branch is where the ORCA adaptation lives, along with the minimal set of core patches that PostgreSQL 19 needs to host all of this.

What a DBA asks before celebrating a benchmark

No benchmark number should circulate without the execution plan behind it, and the same caution applies here. Before treating the result as a verdict, a few basic questions from people who deal with production are worth asking:

• Who measured it, and where? The test was conducted by the extension's own author, on a notebook, without independent review or reproduction on server hardware.
• What does "hot run, best of three" mean? A warmed-up cache favors whoever has a more predictable memory footprint; it doesn't necessarily reflect real production load with cold data and concurrency.
• Does the extension install on its own? Not like a regular CREATE EXTENSION. The project depends on a minimal set of patches to the PostgreSQL 19 core, which sets it apart from a vanilla binary.
• Is the version tested the same one announced as upcoming? The GPU version, mentioned as a next step, is described by the author himself as a rough draft, with no published numbers yet.

In short: the data is real and the telemetry is open for anyone who wants to check it, but this is a one-man benchmark, on a single machine, within a one-month development window. It counts as a sign that the idea has legs, not as proof of superiority in production.

Where this affects data pipelines in Brazil

Many Brazilian teams today keep PostgreSQL as their transactional database and replicate data to ClickHouse (or to a Parquet data lake queried by DuckDB or Trino) just to run heavy analytics. That separation is costly: extra ETL, latency between the two sources, two surfaces for operations and monitoring, and two query-optimization languages for the team to master.

A mature vectorized extension inside PostgreSQL itself would tackle exactly this pain point, allowing heavy analytical queries to run without pulling data out of the transactional database. It's the same promise that already drives pg_duckdb and Citus's columnar storage, each with its own trade-off between maturity and the scope of supported queries. pg_vexec arrives later, with a different technical proposal (vectorization derived from ORCA instead of embedding another engine), but still at a much more embryonic stage than those alternatives.

What's missing to go from laptop to production

For any architect to seriously evaluate pg_vexec as a stack option, there are pieces missing from the announcement: tests on server hardware under concurrent load, coverage of the full set of ClickBench queries (not just a subset), documentation of which core patches would be needed and whether there's a path to submitting them to the PostgreSQL community, and some guarantee of transactional integrity equivalent to what the standard engine offers once execution becomes vectorized.

Until then, Suhorukov's project is a genuinely interesting database engineering experiment, published with open code and verifiable telemetry. It's worth following the repositories and the technical report he published. But swapping ClickHouse or DuckDB for a month-old extension, without testing the execution plan in your own environment, is a decision no careful DBA makes based on the announcement alone.