Greenplum Support Options After Going Closed Source

Greenplum support now comes from Broadcom for licensed VMware Tanzu Greenplum customers, from the vendors behind the open-source forks, and from independent providers who support the Greenplum you already run, whichever version that is. The options changed in 2024, when Greenplum stopped being an open-source project.

What changed: Greenplum went closed source

Greenplum Database was open sourced under the Apache license in 2015. In May 2024 that ended. As the Apache Cloudberry project recorded at the time, nearly all of Greenplum's GitHub repositories were archived and made read-only and the community Slack workspace was deleted, without an announcement. Greenplum is now a commercial product only, sold by Broadcom as VMware Tanzu Greenplum.

For anyone running the open-source build, that means no further community releases and no public security fixes. The Greenplum 6.x or 7.x cluster still works. It just no longer has an upstream.

Option 1: Broadcom support for Tanzu Greenplum

Licensed customers get support from Broadcom for the Greenplum Database versions inside its support lifecycle. Broadcom publishes the dates in a product lifecycle matrix on its support portal, which needs a customer login, so check it for your exact Greenplum version rather than relying on a public summary. This is the only source of new Greenplum releases and product fixes.

Option 2: the open-source forks

Two forks picked up where the open-source project stopped. Apache Cloudberry entered the Apache Incubator in October 2024. WarehousePG is an Apache-licensed fork backed by EDB, which describes it as binary compatible with Greenplum 6.x and 7.x and sells 24x7 support for it. Both are credible paths. Both are also migrations, with the testing that implies for a petabyte-scale data warehousing workload.

Option 3: independent support for the cluster you have

• Open-source Greenplum with no upstream, where you need someone accountable while you decide between Tanzu Greenplum and a fork.
• Older Greenplum versions outside the vendor lifecycle.
• MPP operations rather than product defects: a failed Greenplum segment and mirror recovery, data skew from a bad distribution key, spill files filling disks, catalog bloat, resource queue and statement_mem settings that starve concurrency, gpbackup and gprestore that no longer fit the window.
• The move itself, whether that is an upgrade from 6.x to Greenplum 7, a fork, or a different analytics platform.

AceMQ provides 24/7 Greenplum support with a 15-minute emergency SLA and senior MPP database engineers, for VMware Greenplum and open-source builds, on premises or in public cloud. A typical starting point is an MPP cluster assessment that tells you what state the cluster is really in.

What Greenplum support actually has to cover

Greenplum Database is a massively parallel processing (MPP) database system built on Postgres. A coordinator plans each SQL query and a set of segments run it in parallel, which is what makes it good at analytics and data warehousing and also what makes it fail in its own particular ways. Whoever supports your Greenplum database cluster needs to be fluent in the following, on VMware Greenplum 6.x and 7.x alike:

• Segment and mirror health. A failed Greenplum segment, a mirror that will not resynchronise, a standby coordinator that has drifted. Recovery with the standard utility set, and knowing when a full recovery is safer than an incremental one.
• Query performance. Data skew from a poor distribution key, stale statistics, a schema with append-optimized tables that were never vacuumed, spill files from queries that outgrow their memory limit. Most slow-query tickets are one of these.
• Workload management. Resource queue or resource group configuration, statement_mem and concurrency settings, and the CPU and memory limits that decide which workload wins when the cluster is busy.
• Catalog health. Catalog bloat in tables such as pg_class, and inconsistencies found by gpcheckcat, which turn routine operations into outages if they are left alone.
• Loading and external data. ETL pipelines, external tables, and the Platform Extension Framework (PXF) that connects Greenplum to data sources such as object storage and Hadoop. JDBC and ODBC client connection problems land here too.
• Backup and restore. gpbackup and gprestore jobs that still fit the window and have been tested against a real restore.
• Platform compatibility. Operating system support is the quiet deadline. An older Greenplum version tied to an operating system release that is itself leaving support, on premises or on AWS and other public cloud infrastructure, needs a plan before it needs an emergency.

Broadcom ships a diagnostic toolset, gpsupport, that collects log files and cluster state for a support case. It is worth running whoever you call, because troubleshooting an MPP database without that data is guesswork.

Planning the next move

There is no neutral option any more, so it helps to set them side by side. Licensing Tanzu Greenplum keeps the software you know with a vendor behind it, and ties you to Broadcom's commercial terms and roadmap. Moving to WarehousePG or Apache Cloudberry keeps an open-source MPP database with a familiar architecture. Both are young as independent projects, so look at release activity, the extensions and utilities you depend on, such as PXF, gpbackup and Command Center equivalents, and who would support you. Moving to a cloud warehouse removes cluster operations entirely and means rewriting distribution-aware SQL, external table loads and every ETL job that speaks Greenplum. Whichever you choose, the first step is the same: an inventory of version, data volume, extensions, loaders and the queries that matter, so the options can be tested against facts.

Choosing

If you are licensed and current, Broadcom support is the first call for a product defect. If you run the open-source build, the question is not whether to act but when: get support in place now, then choose between licensing and a fork without an outage forcing the decision.