The Fork Stopped Being a Fork: Cloudberry vs Greenplum

The Greenplum lineage on the left. What Apache Cloudberry (Incubating) added on the right. SynxDB is the commercial distribution on top — the storage/compute separation, console and support are ours, not the Apache project’s.

Two years ago we argued on this blog that Apache Cloudberry (Incubating) was the most natural open source alternative to Greenplum. That was a defensive argument, and it was the right one at the time: your lineage stays open, your governance stops depending on one vendor’s mood.

This post is the sequel, and the argument has changed shape. It is no longer that Cloudberry is a safe place to land. It is that Cloudberry has gone somewhere Greenplum did not.

The Apache project publishes a page documenting how its capabilities compare to the lineage it came from. I would encourage anyone still running Greenplum in production to read it directly rather than take our summary of it. I am a PPMC member on the project and this company builds a commercial distribution on top of it, so we are not neutral narrators. Read the source, then read us.

What that page quietly documents is that the compatibility story and the divergence story have become two different stories.

Compatibility is still the on-ramp

The project’s own framing is that Cloudberry “is built on the open-source lineage of Greenplum Database and is highly backward-compatible with Greenplum.” That holds up in the field. Most DDL, most ETL, and most application logic move across without a rewrite.

We would rather be specific about the exceptions than let “unchanged” do work it cannot do. The ones that reliably come up:

• Resource queues — the model differs and needs to be re-expressed.
• Some external table definitions — most carry, a subset needs rework.
• Extension coverage — check your list against the target before you scope anything.

Any DBA who has actually run a migration knows there is always a list. Ours is short, it is known in advance, and it is written down in our Greenplum to SynxDB migration guide. That is the part that matters when you are estimating.

So the on-ramp is real. But an on-ramp is not a reason to move. This is.

Sixteen capabilities that only exist on one side

Storage and lakehouse

Capability	What it does
Directory Table	Unified SQL management of unstructured data on local or object storage.
PAX Storage Format	Hybrid row-column format — batch-write performance of row storage, read performance of columnar, better cache efficiency.

Together these answer a question Greenplum’s architecture never had to ask: what happens when the warehouse has to sit next to a lake.

Query performance

Capability	What it does
Incremental Materialized Views	Refreshes only changed data instead of rebuilding the view.
Automatic MV Rewrite	The planner uses incremental MVs to answer queries not written against them.
Dynamic Tables	MV-like objects that refresh automatically on a schedule.
Parallel Query Execution	Multiple CPU cores on a single query per segment, for heap and AO/AOCO scans.
RuntimeFilter for Join	Bloom filters pre-filter large tables ahead of a HashJoin.
IndexScan on AO Tables	Cuts data scanned on ORDER BY / LIMIT queries against Append-Optimized tables.
Unique Index on AO Tables	Unique indexes and constraints enforced at the storage engine level.

Read that as an operator rather than a spec reader. Incremental MVs plus automatic rewrite replaces workloads you previously solved with a nightly rebuild and a lot of hope. Unique constraints on AO tables means the storage engine now enforces something your ETL was enforcing by convention — and convention is what breaks at 3am. For what this adds up to under load, see our SynxDB vs Greenplum benchmark.

Security

Capability	What it does
Transparent Data Encryption	Encryption at rest, AES and SM4, two-tier key management.
Row-Level Security Policy	Table owners define per-user row filtering.
Password Policy	Named profiles for complexity, expiration, lockout, and reuse.

This is the group that gets deals unstuck. Every enterprise security review asks the same three questions, and until recently the honest answer for this class of system was “at the filesystem layer, and separately.”

Deployment and operations

Capability	What it does
Single Node Deployment	Run without segment nodes for dev, test, or light production.
ARM Architecture Support	Full ARM/AARCH64 support.
gpshrink	Scale a running cluster in by removing segments from underutilized hosts.
gpdemo	A real multi-segment cluster from one command.

ARM matters more than it reads. It changes the hardware conversation in markets where x86 procurement is the constraint, and it changes the cost conversation everywhere else. gpshrink is the rarer thing — most distributed systems make scaling out easy and scaling in someone else’s problem.

One more item that is not on the feature list but should be: the main branch now tracks PostgreSQL 16.x, with the current stable line on 14.x. Kernel currency is not a headline. It is the thing that determines whether you inherit the wider Postgres ecosystem’s work for free or keep paying to backport it, year after year.

What this changes about the decision

If you run Greenplum today, the question you have probably been asking is what is the risk of moving.

That was the right question when the destination was a compatible re-host. It is the wrong question now, because it prices only one side of the ledger.

The other side is what you do not get by staying. Not a vendor’s roadmap — a community’s. Cloudberry’s development happens in the open under Apache Software Foundation incubation, with 30+ committers and public mailing lists, Slack, and GitHub Discussions. You can read the argument before the feature lands. You can be in it. That is not an abstract governance nicety. It is the difference between a roadmap you are told about and one you can influence. We wrote separately about what the licensing change means for open source users.

The project is still incubating, and we will say that plainly rather than let it be inferred. Incubation is a governance status, not a maturity claim about the code — but it is the accurate description, and anyone evaluating this should know it before a procurement team finds out on their own.

Where Synx comes in, and where we do not

We build SynxDB on Apache Cloudberry. The line between the two matters, and blurring it is how vendors lose technical audiences.

Everything above is the Apache project. It is Apache 2.0 licensed, and you can run it in production without talking to us or to anyone else. The mailing lists are open to anyone. If that is where you land, good — it is still a win for the project.

What we add is the layer enterprises ask for once the engine decision is made:

• Storage and compute separation, with scaling in seconds. A SynxDB Cloud capability, not an Apache Cloudberry one — Cloudberry inherits the shared-nothing architecture. We are explicit about this because the distinction is real.
• A management console for cluster, resource, and metadata operations.
• Infrastructure-agnostic deployment — move between infrastructures without code changes.
• Migration tooling sized for real data volumes, not just the demo case.
• Commercial support and lifecycle commitments — in writing, in a form a regulated buyer’s procurement process will accept.

We put the two side by side in Cloudberry vs SynxDB. Some teams need that layer. Plenty do not. Both outcomes are fine.

The actual point

Two years ago the argument for Cloudberry was defensive: your lineage stays open.

Today the feature list makes an offensive argument, and it is a more durable one. The compatibility keeps the migration cheap. The divergence is what makes it worth doing.

If you are mid-decision on a Greenplum estate, read the comparison yourself and form your own view: cloudberry.apache.org.

Then, if you want a second opinion on the migration plan — including one that concludes you should stay put — talk to us.

FAQ

Is Apache Cloudberry compatible with Greenplum? Largely, yes. The project describes itself as built on the open-source lineage of Greenplum Database and highly backward-compatible. Most DDL, ETL, and application logic carry over. The exceptions that reliably need attention are resource queues, some external table definitions, and extension coverage.

What PostgreSQL version does Apache Cloudberry use? The main development branch tracks PostgreSQL 16.x. The current stable branch, REL_2_STABLE, tracks PostgreSQL 14.x, with ongoing minor upgrades and a newer kernel planned for the 2.x line.

Has Apache Cloudberry graduated from the ASF incubator? No. It is Apache Cloudberry (Incubating) and remains under incubation. That is a governance status rather than a statement about code maturity.

What is the difference between Apache Cloudberry and SynxDB? Apache Cloudberry is the open source project. SynxDB is our commercial distribution built on it, adding a management console, infrastructure-agnostic deployment, migration tooling, and commercial support. SynxDB Cloud additionally provides storage and compute separation with scaling in seconds — a capability of our product, not of the Apache project.

---

Tushar Pednekar is Co-founder of Synx Data Labs and a PPMC member of Apache Cloudberry (Incubating).