· Tushar Pednekar
41 CVEs and One Minor Version: Apache Cloudberry 2.2.0
Cloudberry 2.2.0 moves the kernel to PostgreSQL 14.9, closes 41 CVEs that 2.1.0 does not, and adds quota, observability and tiered-storage extensions.
Apache Cloudberry (Incubating) has published a preview of what is coming in 2.2.0. It is worth reading carefully, and not for the reason release notes are usually worth reading.
There is no headline feature here. No new storage format, no new execution engine, nothing you would put on a slide. What 2.2.0 has instead is a patch cadence, a CVE ledger, a platform matrix with CI behind every row, and packaging that installs the way your configuration management already expects. Those are the boring properties, and they are exactly the properties an enterprise platform team asks about before they will let a new engine near production.
One caveat up front, and it matters: 2.2.0 has not been released. The Apache project’s post describes the current release candidates, and the final contents can still change before the release is approved. Nothing below is a commitment from the project, and nothing below is a commitment from us.
The kernel is now on a schedule
The most consequential line in the whole preview is the least dramatic one: the kernel has moved from PostgreSQL 14.4 to 14.9, and the project says the work continues one minor version at a time until PostgreSQL 14 reaches the end of its upstream life.
Read that as a process change rather than a version bump. A fork that sits on a pinned PostgreSQL minor accumulates a debt that has to be paid in one painful lump later. A fork that tracks upstream minors absorbs security and correctness fixes incrementally, in increments small enough to test. The first model produces a scary migration every few years. The second produces a boring upgrade every few months.
The 41 CVE fixes that 2.2.0 carries and 2.1.0 does not are the visible output of
that change. They span privilege-escalation checks, memory-safety hardening
across the parser, the regex engine, text search and pgcrypto, injection
issues in backup utilities, and path traversal. If you have ever had to answer a
security questionnaire about an analytics engine — how do you take upstream
PostgreSQL fixes, and how fast — this is the paragraph you were looking for.
Platform support got narrower and better tested
2.2.0 supports Rocky Linux 8, 9 and 10, and Ubuntu 22.04 and 24.04. Rocky 10 and Ubuntu 24.04 are new. Ubuntu 20.04 is dropped — if you are still on it, plan that upgrade before you plan the 2.2.0 move, not after.
More interesting than the list is what sits behind it: CI coverage across all five platforms with matrix-driven workflows, and automated DEB and RPM builds for both x86_64 and ARM64. The RPMs are relocatable and support major-version coexistence, which is a small detail with a large operational consequence — it means you can stage a new major alongside the running one on the same host instead of negotiating a maintenance window to find out whether it installs.
A supported-platform list that no one tests is marketing. A supported-platform list with a CI matrix behind it is a commitment.
Six extensions, and what each one is actually for
The preview adds six extensions. Grouped by the problem they solve:
Stopping a cluster from being ruined by one team. diskquota enforces disk
usage limits per schema and per role. reject_partition_fullscan rejects
queries against partitioned tables where no partition pruning happened — the
single most common way a well-meaning analyst turns a partitioned fact table
into a full scan and takes the cluster with it.
Seeing what is happening. gp_stats_collector collects query execution
metrics and reports them over a Unix domain socket. gp_relsizes_stats
calculates and stores file and table size statistics on hosts. Both are plumbing
for the monitoring you already wanted.
Making queries survive bad data. try_convert provides error-safe casts that
return a default instead of aborting the statement. Anyone who has had a nightly
load die on one malformed row knows the value.
Tiering cold data off local disk. yezzey offloads AO and AOCO table data to
S3-compatible object storage. This is worth being precise about: it is tiered
storage for cold data, not storage/compute separation. Apache Cloudberry remains
a shared-nothing MPP architecture. True storage/compute separation is a
commercial capability in SynxDB Cloud, not something the Apache project ships.
Conflating the two sets up a disappointment later, so we do not.
Day-2 operations: PXF finally tells you what it is doing
PXF 2.2.0 adds pxf_stat_activity, a view showing what is running inside the PXF
server — one row per active operation, with segment ID, session ID, command
count, transaction ID, user, server, profile, schema, table, data source and
start time. Alongside it, pxf_cancel_backend and pxf_interrupt_backend let
you stop a runaway external-table query without restarting PXF.
If you have operated a federation layer, you know the old failure mode: a query against an external source hangs, you cannot see which one, and the only lever you have is a restart that takes everyone else’s queries down with it. That lever is now a scalpel.
Java 17 is supported for building (alongside 8, 11 and 21), artifacts still compile to Java 8 bytecode for backward compatibility, and Log4j moves to 2.25.4 — which is the sort of dependency line security review reads first. Testcontainers-based coverage now spans ClickHouse, Oracle, SQL Server over JDBC, and S3. Parquet UUID types are readable and writable. Filter pushdown extends to numeric columns compared against integer constants.
Backup grew a management layer
Two new commands land in the 2.2.0 backup tools.
gpbackman manages backups directly from the gpbackup_history.db SQLite
database: reporting on what exists, deleting by age or criteria, reaching both
local and plugin-based storage, cleaning the history database, and synchronizing
history with the standby coordinator. That last item is the one that bites people
— a coordinator failover that loses backup history is a bad afternoon.
gpbackup_exporter is a Prometheus exporter, default port 19854, exposing backup
status, deletion status, metadata, duration, and time since last backup. Which
means “when did this cluster last back up successfully” becomes an alert rule
instead of a question someone has to go answer.
gprestore --resize-cluster now works with --jobs greater than 1, which
matters for anyone restoring into a differently-sized cluster on a clock.
Query processing, briefly
There is engine work in here too: interconnect statistics exposed through three new views covering UDP protocol metrics, parallel table scans within a segment via the ORCA optimizer, parallel Hash Full Join and Right Join, and AQUMV extended so automatic materialized-view rewrite can match multi-table joins rather than single-table queries only.
We are deliberately not attaching numbers to any of that. The release candidates are not final, we have not benchmarked them, and a number published today becomes a number someone quotes back at us in a procurement meeting next year. When we have measured 2.2.0 on hardware we control, we will publish what we measured and how.
What we think this means
Two years of argument about Apache Cloudberry has been about licensing and governance. That argument is defensive, and it is largely settled. 2.2.0 is evidence of a different thing entirely: a project with 30+ committers behaving like a release train — tracking upstream, publishing a CVE delta, testing every platform it claims, shipping packages that install cleanly on ARM64, and adding the quota, observability and backup-management pieces that only matter once real workloads are on the thing.
That is the checklist an engine has to pass before a bank or a payments platform will run it. Features get you into the evaluation. This is what gets you out of it.
Disclosure: Tushar Pednekar is a co-founder of Synx Data Labs and a PPMC member of Apache Cloudberry (Incubating). Synx Data Labs builds SynxDB, a commercial enterprise data warehouse and AI/ML platform on Apache Cloudberry, and therefore has a direct commercial interest in the project’s adoption. Apache Cloudberry is an effort undergoing incubation at the Apache Software Foundation.
For SynxDB users: we track upstream Cloudberry releases and qualify them
before they reach SynxDB. If you want to know where a specific 2.2.0 change lands
for your deployment — particularly the CVE set, the Ubuntu 20.04 drop, or
diskquota — talk to us.
Frequently asked questions
Is Apache Cloudberry 2.2.0 released? Not yet. The Apache project has published a preview of the current release candidates. Final contents may change before the release is approved.
What version of PostgreSQL does Apache Cloudberry 2.2.0 use? The kernel moves from PostgreSQL 14.4 to 14.9. The project states it will continue tracking PostgreSQL 14 minor releases one at a time until PostgreSQL 14 reaches the end of its upstream life.
How many CVEs does Cloudberry 2.2.0 fix?
The preview states 2.2.0 carries 41 CVE fixes that 2.1.0 does not, covering
privilege escalation, memory safety in the parser, regex engine, text search and
pgcrypto, injection issues in backup utilities, and path traversal.
Which operating systems does Cloudberry 2.2.0 support? Rocky Linux 8, 9 and 10, and Ubuntu 22.04 and 24.04. Ubuntu 20.04 is dropped.
Does Apache Cloudberry support storage/compute separation?
No. Apache Cloudberry is shared-nothing MPP. The yezzey extension offloads
AO/AOCO data to S3-compatible object storage for tiered workloads, which is cold
tiering rather than storage/compute separation. Storage/compute separation is a
commercial capability of SynxDB Cloud.
Can I cancel a stuck PXF query without restarting PXF?
In 2.2.0, yes — pxf_cancel_backend and pxf_interrupt_backend stop a backend
without a PXF restart, and pxf_stat_activity shows what is running.