[Proposal] Apache Cloudberry as PostgreSQL 19 Extensions

[igor-suhorukov]

Proposers

Igor Suhorukov (@igor-suhorukov)

Proposal Status

Under Discussion

Abstract

Updated 2026-10-08: what has been built on the port since the first version, a vectorized executor and an Arrow Flight SQL endpoint (Motivation, Implementation), and current figures: 24 core commits, 744 test files, the progress of isolation2. The first comments refer to the version of 2026-09-30.

I would like to discuss running Apache Cloudberry on PostgreSQL 19 as a set of extensions on top of 24 dormant core hooks, instead of a forked kernel. A working prototype exists; it is my personal experiment, not an ASF release. Without the modules, the patched server is measurably vanilla PostgreSQL 19: the same PostgreSQL tests pass, the ABI is unchanged, catalogs are byte-identical, and the hooks add less than 0.2% to executed instructions. With them, it is a Greenplum-style MPP engine with plan slices, Motions, two-phase commit and distributed snapshots, running unmodified ORCA and stock PostGIS and pgvector. ORCA plans all 121 TPC-H and TPC-DS queries at SF1 with answers matching DuckDB's, and 744 of Cloudberry's 1,180 test files pass so far.

The port gives users more than a newer PostgreSQL. With Cloudberry's components as modules, new capabilities arrive as further extensions. pg_vexec, built on the port without a single new core patch, adds vectorized execution that ORCA plans by cost, PAX and ao_column tables read and written by column, Arrow frames between segments, and an Arrow Flight SQL endpoint for BI and ML clients.

Claude Code wrote the code, the port over 12 days and 629 commits and pg_vexec over three days; I set the goals and signed off every change to the PostgreSQL core.

Motivation

Greenplum and Cloudberry have always followed PostgreSQL a few releases behind: Greenplum 6 shipped on PostgreSQL 9.4, Greenplum 7 on 12, Cloudberry 2.x on 14, and main reached 16.9 in May 2026. The reason is structural. Cloudberry edits 882 PostgreSQL backend and header files, so every new PostgreSQL major is a large merge. #1095 estimated the 14 → 16 upgrade at 4–5 months, three of them for fixing regression tests, and noted that PostgreSQL 14, the base of Cloudberry 2.x, reaches end of life in 2026. Meanwhile PostgreSQL 17 and 18 have shipped, and 19 is close to release.

In #1877, the project named close compatibility with modern PostgreSQL as one of its goals. The prototype tests whether that goal can become cheap to sustain. If Cloudberry runs as extensions, the next PostgreSQL major means rebasing a small patch series instead of merging a fork. Users get a current PostgreSQL, including PostgreSQL 19 features such as eager aggregation and parallel autovacuum. They also get stock extensions: upstream PostGIS 3.7 instead of a PostGIS fork, and pgvector 0.8.6 built unpatched, which is relevant to #2043.

More than a newer PostgreSQL. A current base is the first gain, not the only one. As modules, Cloudberry's planner, storage and interconnect can be combined with other extensions, so new capabilities arrive as extensions rather than as more changes to a fork. Apache Cloudberry's code has no vectorized executor: only traces of a closed-source engine remain, a create_vectorization_plan flag the planner always passes as false, a WindowHashAgg node with no executor behind it, and a PAX adapter under VEC_BUILD that no longer compiles. pg_vexec was built on top of the port in three days of implementation (write-up), and it brings Cloudberry users:

• Vectorized execution, chosen by cost. Batches of up to 1,024 rows by column replace the row-at-a-time loop on the coordinator and on every segment. ORCA weighs vector nodes in its search (CCostModelVec) and its translator builds them; PostgreSQL's planner gets them through its path hooks. No finished plan is rewritten, and a fallback to PostgreSQL's expression evaluator inside the same node keeps PostgreSQL's semantics.
• Columnar storage without rows. PAX and ao_column hand batches to the executor and take them back on insert. count, min, max, sum and avg without conditions come from PAX's statistics: count(*) over 10 million rows takes 0.33 ms instead of 265.
• Arrow between segments. Motions carry Arrow IPC frames, routed by a vectorized cdbhash that reproduces GpHashSegment bit for bit, and a new shm interconnect passes them through shared memory between the segments of one host.
• Arrow Flight SQL. vexec_flight serves results as Arrow record batches straight from the executor, and adbc_ingest() loads DataFrames into tables, by column into PAX and ao_column, with the standard ADBC Flight SQL and Flight SQL JDBC drivers. Logins are checked against pg_hba.conf and statements run through portals, so privileges, RLS and pg_stat_statements behave as they do over pgwire, which stays as it is.
• PostGIS and pgvector over batches, through kernel packs that declare which of their functions may be called on a batch's rows, without changing either extension.

These are first measurements, and partial ones; every answer was checked against DuckDB's. On one node, on ClickBench at 10 million rows, vexec in auto mode takes 19–24% off PostgreSQL's planner and 16–19% off ORCA by geometric mean, and the best queries run 8.8–9.5× faster, though a few got slower; Flight SQL delivers a million lineitem rows 4.7× faster than binary COPY and loads PAX 1.65× faster than COPY CSV. On four segments TPC-H Q1 runs 1.8–2.8× faster, but the first TPC run, with only scans and aggregates vectorized, averaged about 1×; the cluster's measurements with vectorized hash joins and Arrow frames through Motions are next.

None of it needed a new core patch: vexec also runs on vanilla PostgreSQL 19, and gp_orca now builds for it without gp_core (-Dorca_single_node), so ORCA plans vector nodes on a stock server too. It relies on what PostgreSQL added after 16: heap_prepare_pagescan (17), explain_per_plan_hook (18), and planner_setup_hook, planner_shutdown_hook and the batched visibility check HeapTupleSatisfiesMVCCBatch (19), none of which Cloudberry's main has. In a fork, each such capability would be one more set of kernel changes to carry across every PostgreSQL major.

The prototype compiles Cloudberry's own sources in place, so it builds on the community's work rather than replacing it.

Implementation

Details: Greenplum Without the Fork. Code: core series, port, build instructions.

The ground rule: a server with the core patches but without Cloudberry loaded must be indistinguishable from vanilla PostgreSQL 19, and this is measured.

• Core series: 24 commits, 49 files, +1,622/−41 lines. Existing extension points come first: hooks, table AMs, CustomScan, custom WAL resource managers, background workers, security labels and FDWs. Where they are not enough, a new hook is a NULL-by-default function pointer, a new exported function, a registration list or an off-by-default flag. No existing signature changes, no struct gains a field, and no catalog, WAL, page or protocol format changes.

• Vanilla checks compare Docker images built from the same PostgreSQL commit with and without the series:

  • the same 371 meson test results;
  • abidiff: 34 symbols added, 0 changed;
  • byte-identical catalogs, settings, keywords and stored parse trees;
  • identical query IDs;
  • interchangeable data directories and streaming replication;
  • cachegrind: −0.011% to +0.160% executed instructions;
  • a script that checks every statement added inside an existing function sits behind a hook, registry or flag, with one reviewed exception.

• Cloudberry's tree is untouched. The whole port is one new directory, pg19/, plus a release workflow in .github/workflows. Cloudberry's files compile where they lie, so merges from Cloudberry keep applying, and a file that must change becomes a copy that says what changed. ORCA's 920 core files compile unmodified behind planner_hook, and PAX compiles in place with 57 of its 91 files unchanged.

• Modules:

  • gp_core: dispatcher, Motions, interconnect, 2PC, distributed snapshots, GDD, FTS;
  • gp_orca;
  • gp_sql: Cloudberry syntax rewritten into PostgreSQL 19's grammar;
  • storage: gp_ao, pax;
  • external data: gp_exttable, pxf_fdw, gpcloud, datalake_fdw;
  • gp_resource, gp_security, gp_matview, gp_task, diskquota;
  • gpfts and gpMgmt's tools from gpinitsystem to gpexpand.

• Built on the port since: pg_vexec, in its own repository: vexec (about 43,000 lines of C), vexec_flight (7,900) and the kernel packs for pgvector and PostGIS (1,000). vexec builds with PGXS both for vanilla PostgreSQL 19 and for the port. Its side of the port is module code in pg19/, about 13,600 lines with the shm transport and PAX's copies: gp_orca's API for vector nodes and CCostModelVec, gp_core's API 1.15 (a Motion rebuilt by another module, the distribution's hash functions, squelch_subtree(), figures in EXPLAIN ANALYZE), and PAX's and gp_ao's batch readers and sinks. vexec calls none of the core patches.

• What changes for users:

  • migration is logical (dump and restore);
  • settings are renamed gp.*, although gpconfig accepts the old names;
  • DDL command tags become standard;
  • the 20 shared catalogs are replaced by security labels, extension tables and a cluster file;
  • TDE gives way to volume encryption.

Rollout/Adoption Plan

Nothing here affects Cloudberry 2.x or the 3.0 plans: the prototype lives in my fork and changes no lines in Cloudberry's files. I would like to ask the community for four things:

1. Feedback on the direction. Is running Cloudberry as PostgreSQL extensions worth pursuing as a long-term path after 3.0?
2. A home for pg19/. It is one directory that tracks Cloudberry's sources without editing them. If the direction looks right, would the project consider hosting it, for example as an experimental branch or a separate repository?
3. Help with the remaining tests. The goal is to pass Cloudberry's original test suites with minimal changes to the tests. Every skipped test is listed with the statement that stops it, so tests are easy to pick up. isolation2_schedule now runs 113 of its 262 tests in both passes (60 when this was first posted); its 133 append-optimized tests and the 95 skipped tests of greenplum_schedule are next.
4. A decision on Route B. Should the port bring over Cloudberry's MPP variant of the PostgreSQL planner (30–45k lines), or keep shrinking ORCA's declines? On the regression suite, the port's own fallback reasons already fell from 563 to 52. A proposed gp.mpp_planner switch would allow side-by-side comparison, and I would value the view of the planner experts here.

For users, migration would be logical, similar to the cluster-to-cluster copy planned for 2.0 → 3.0 in #1095. Separately, four of the custom hooks (table AM registry, smgr file events, parser hook and OID hook) are general enough to propose to PostgreSQL upstream. Support from Cloudberry developers as their real-world user would strengthen that case.

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

[leborchuk]

Hi!

Thank you for the attention to our project )

The article https://github.com/igor-suhorukov/cloudberry/blob/extension_postgresql_19/pg19/doc/greenplum-without-the-fork.md looks more broader and has more interesting details, if you don't mind I'll answer mainly to ideas from you original post rather than technical description here. Because some aspects need discussion at first and only then implementation.

1. Kernel rebasing. It's the major reason why you need community. You cannot offload this task to LLM or whatever else. Of course, LLM will spend you tokens easily and you even could get some looks promising result. But without owning the code you won't get good basement for your further improvements. If you could generate whatever you want why one could need cloudberry at all? Or you just could ask LLM to rebase cloudberry to PG19 (it also complete task in a few days).

Ease rebasement - what we constantly bear in mind. And the story we usually share with postgres community. You could get postgres, add here PAX - and now you have analytical data storage format. And the same with other new components. There are not so much of them comparing with original greenplum innovations. But now it's just the matter of time. There will be more and more components, I believe )

It will be great to evolve old approaches and make them extension-based. For example, as you described - make ao and aoco tables as extensions. We could start with some specific functionality and then step-by-step goes to the situation where you have postgresql fork extended with various MPP functions. Not based on postgres our own MPP database. The difference of course in the number of changes in a core part (and conflicts need close attention) and code reusing.

The idealistic (I think it's too simple to be true) picture is you have a set of extensions and combining them could easily make your own specific database.

How to achieve this - if you are really interested in it and ready to participate, let's continue discussion (good example is #1683 ), volunteer project developers and gradually improve our codebase. LLM will help us, but not replace, we still need to clearly understand what we are doing.

2. Clickhouse benchmarks

Kernel rebasing is great but as you have written, we rebase kernel not to the sole kernel version but to achieve something - new functionality or better performance. Good example is clickbench - new kernels could get you better performance. But I need to say modern PG kernel is not enough. PG is just (not fully describe current situation but it's too hard to express it succinctly) not good enough to beat clickhouse in clickbench. Not because clickbench purposely was written by clickhouse developers to beat all other competitors (but because of that, too), but mainly because clickhouse constantly compact (sort) data in background and have many others good improvements. We also could improve our group by facilities and be comparable in some aspects with clickhouse. It's possible, but not easy. if you interested - feel free to create discussion. I believe we could do it.

Also we could create our own benchmark to beat all the competitors in it.

3. Not only Postgres

You mentioned other Postgres-related projects. We could not only compete with them but also get good approaches from them.
For example ORCA (and some other GP components) also is used by polardb - database with shared-everything architecture. We also could get some good approaches from polardb and use it in cloudberry. I'am not good at polardb to say which one - it was just a suggestion. But if you have good candidates - let us know.

[yjhjstz]

Hi @igor-suhorukov,

Thanks for this impressive experiment. It shows something many of us assumed was impossible: distributed snapshots, 2PC and shared reader/writer transactions running on a small set of dormant hooks, with ORCA compiled unmodified behind planner_hook. I agree that an extension-based Cloudberry is the right long-term direction. Following PostgreSQL a few majors behind is a structural problem, and this is the most credible answer to it I have seen.

That said, I don't think the community should adopt the prototype as it is, for five reasons:

1. It is a different product, not the next version. Upgrading requires dump/restore, GUCs are renamed to gp.*, the shared catalogs and TDE are gone, and DDL command tags change. For existing 2.x users that is a migration to a new system, which makes it hard to position as Cloudberry's successor.

2. The riskiest parts are not yet verified. Transaction semantics rest on new mechanisms: XactAdoptTransactionState(), segments waiting on prepared transactions, and a replication slot holding back VACUUM. isolation2, the suite that exercises exactly these paths, has not passed yet, and overall coverage is 691 of 1,180 test files. Until those pass under concurrency, correctness is an open question.

3. The performance cost is not measured. Dispatching each slice as SELECT gp_internal.exec_fragment(...) over libpq, and passing the snapshot as SET LOCAL, adds overhead on every query. The TPC results (SF1, one container, parallel off) show correct answers, not performance. We would need short-query latency, high-concurrency throughput and larger-scale numbers before comparing it with the native dispatcher.

4. It is still a fork, only a smaller one. Of the 22 hooks, four look upstreamable. The other 18 mean maintaining a patched PostgreSQL indefinitely, so users still can't run on stock or managed PostgreSQL. The maintenance burden shrinks but does not go away.

5. Code ownership. About 600 commits written in 12 days is a remarkable result, but the community would inherit a ~33k-line translator and a new transaction layer that nobody here knows deeply yet. As @leborchuk said, rebasing and long-term evolution depend on people who own and understand the code.

My suggestions:

1. Evolve from main incrementally instead of replacing it. Start with modules that have clear boundaries and need no deep kernel changes, such as AO/AOCS as table AMs, external tables as FDWs, and the gp_sql syntax layer. Use pg19/ as the reference implementation and requirements list, not as a drop-in replacement.

2. Upstream the general-purpose hooks first. The table AM registry, smgr file events, parser hook and OID hook would benefit PostgreSQL broadly, and Cloudberry can back them as a real-world user. Every hook accepted upstream lowers the cost of the extension approach for good.

3. Validate the transaction layer before going further. Get isolation2 passing and publish short-query latency and concurrency benchmarks against the native dispatcher. That data should decide whether the MPP core can move to extensions, not the other way round.

4. On Route B: don't port it; keep reducing ORCA fallbacks. Porting 30–45k lines of the MPP planner would recreate the very merge burden this effort is trying to remove. Fallback reductions (multi-level partitions, aggregate FILTER, LATERAL, non-default collations) benefit both main and the extension port. ORCA is also the natural first shared component, since its core does not depend on PostgreSQL headers and only the translator tracks the PostgreSQL version.

5. Host it as a separate experimental repository. Something like cloudberry-pg-ext keeps the work visible and open to contributors without implying it is the official roadmap. That separation can be revisited once items 2 and 3 have results.

[igor-suhorukov]

@yjhjstz @leborchuk thank you for sharing your expert opinion!

@yjhjstz thanks, point 2 is fair, so I took it as a test plan.

Today the port runs 60 of the 262 tests in isolation2_schedule, plus 14 of the 15 parallel retrieve cursor tests. These are the ones on distributed transactions, snapshots, locks, GDD, FTS
and mirrors, and each runs under the planner and under ORCA.

Among them, reader_waits_for_lock reaches XactAdoptTransactionState(), under ORCA. distributed_snapshot, distributedlog-bug and gdd/concurrent_update reach the hidden-commit path.
vacuum_recently_dead_tuple_due_to_distributed_snapshot reaches the slot.

None of Cloudberry's tests reaches a segment waiting on a prepared part. Cloudberry's coordinator PANICs rather than end a transaction with a part still prepared, so its tests never get
there. I added tests for it.

Added after your comment:

1. igor-suhorukov/cloudberry@3f2b6df967a: fix. A lost wake-up of the recovery process could leave a prepared part, and every reader on its segment, waiting 5 minutes.
2. igor-suhorukov/cloudberry@d054391a681: isolation2 port/dtx_wait_prepared. A reader waits on a segment for a prepared part (336 s before the fix, 35 s after).
3. igor-suhorukov/cloudberry@3dbbc77a1b0: isolation2 port/dtx_horizon. The VACUUM test runs with and without the slot (38/37/25 rows vs 0/37/25), as a negative control.
4. igor-suhorukov/cloudberry@76bb3ae76ef: combocid_readers. combocid_gp's checks, counted, with ORCA's readers asserted.
5. igor-suhorukov/cloudberry@ac1eb409d76: dtm_retry's skip reason corrected.

Full run on that commit: isolation2 80/80 in both passes, greenplum_schedule 392/392 and 394/394.

Still to do: the other 200 isolation2 tests (133 of them append-optimized) and latency and concurrency benchmarks (your point 3).