GitHub user igor-suhorukov edited a discussion: [Proposal] Apache Cloudberry as PostgreSQL 19 Extensions
### Proposers Igor Suhorukov ([@igor-suhorukov](https://github.com/igor-suhorukov)) ### Proposal Status Under Discussion ### Abstract *Updated 2026-10-12: 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, 873 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](https://github.com/igor-suhorukov/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](https://github.com/apache/cloudberry/discussions/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](https://github.com/apache/cloudberry/discussions/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](https://github.com/apache/cloudberry/discussions/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](https://github.com/igor-suhorukov/pg_vexec) was built on top of the port in three days of implementation ([write-up](https://igor-suhorukov.github.io/blog/2026/10/07/vectorized-postgresql-extension/)), 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](https://github.com/igor-suhorukov/cloudberry/blob/extension_postgresql_19/pg19/doc/greenplum-without-the-fork.md). Code: [core series](https://github.com/igor-suhorukov/postgres/tree/REL_19_STABLE_CLOUDBERRY), [port](https://github.com/igor-suhorukov/cloudberry/tree/extension_postgresql_19/pg19), [build instructions](https://github.com/igor-suhorukov/cloudberry/tree/extension_postgresql_19/pg19#building). 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](https://github.com/igor-suhorukov/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](https://github.com/apache/cloudberry/discussions/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? - [X] Yes I am willing to submit a PR! GitHub link: https://github.com/apache/cloudberry/discussions/2065 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
