Choosing an open source PostgreSQL operator for Kubernetes used to be a question about features and community size. In 2026, it has become a question about licensing posture, image distribution, and whether the project you pick today will still be operationally open in three years.
TL;DR
- MinIO is archived. Bitnami's free catalog got cut. Crunchy Data's official images come with redistribution and consulting restrictions. "Open source" today is doing less work than it used to.
- Three questions decide whether an operator is operationally open or just source-available: are the container images publicly redistributable, are core operational features in the open-source build, and is the roadmap genuinely public.
- Percona's PostgreSQL Operator hard-forks at v3.0.0. Fully redistributable images, public roadmap, public issue tracker. This post is the why; parts 2 and 3 are the how.
This is part 1 of a 3-part series on running PostgreSQL on Kubernetes with a fully open-source operator.
- Part 1 (this post): how the open-source landscape has shifted under your feet, and what to look for in an operator before you commit
- Part 2: migrating from the Crunchy Data PostgreSQL Operator to the Percona PostgreSQL Operator using the standby cluster method (near-zero downtime)
- Part 3: two simpler migration paths: backup-and-restore and persistent-volume reuse
In this post, you will learn about:
- What changed in the open-source landscape over the last few years, with specific examples
- What licensing and redistribution restrictions actually mean for Kubernetes operators in production
- How to evaluate whether a project is "open source in theory" or open source in practice
- Where Percona's PostgreSQL Operator fits in, and what the practical migration looks like
Open source isn't what it used to be
The landscape of open source has undergone significant changes in recent years, and selecting the right operator and tooling for PostgreSQL clusters in Kubernetes has never been more important. Three recent shifts illustrate the pattern.
MinIO
MinIO was, for years, the default open-source S3-compatible storage backend for Kubernetes workloads. The trajectory over the last few years tells the story:
- Switched its license to AGPLv3, with several enterprise features moved into a commercial-only edition
- Entered what amounted to maintenance mode, narrowing community engagement, limiting support to paid subscriptions, and reducing acceptance of community contributions
- On April 25, 2026, the github.com/minio/minio repository was archived by the project owner, ending public development of the open-source version
The code is still cloneable, but the project is no longer maintained as open source. Teams running MinIO in production now need an exit plan.
Bitnami images
Bitnami Docker images have long been a staple for databases (including Postgres), middleware, and developer tooling. In July 2025, Broadcom's Tanzu Division announced Bitnami Secure Images and signalled the deprecation of the free public catalog. The concrete timeline that followed:
- August 28, 2025: deprecation of non-hardened Debian-based images in the free tier began, and non-latest images started to be removed
-
September 29, 2025 (after community pushback): the public
docker.io/bitnamicatalog was reduced. The remaining free images were limited to a small curated set of latest-version, hardened images intended for development use; older versions of most applications were moved to a "Bitnami Legacy" repository - The full catalog and the hardened production images now require a paid Bitnami Secure Images subscription, reportedly priced in the tens of thousands of dollars per year per organization
For Kubernetes teams, the practical impact was immediate: any Helm chart that pinned a specific Bitnami image version (a recommended practice) found that image gone or moved, breaking CI pipelines and air-gapped deployments.
Crunchy Data PostgreSQL images
Crunchy Data illustrates the same dynamic in the Postgres operator space. To be clear: the Crunchy Data PostgreSQL Operator is a mature, well-engineered project, and the team behind it has done a lot of valuable work upstream and around pgBackRest and Patroni integrations. The point of this section is not the engineering, it is the redistribution and usage terms that govern the official builds.
Crunchy's licensing shifts, 2022 to 2024
Between 2022 and 2024, several shifts occurred:
- Redistribution restrictions. While the PostgreSQL code is open source, Crunchy's official Docker images include branding and enterprise features that are not freely redistributable. The Crunchy Data Developer Program terms describe the software as intended for internal or personal use; production use by larger organizations typically requires an active support subscription.
- Restrictions on consulting and resale. The terms explicitly prohibit using Crunchy's images to deliver support or consulting services to others without an authorized agreement. The PostgreSQL source itself remains open source, but the official images and the way they are packaged are not freely redistributable, which limits practical use in commercial and customer-facing settings.
-
Registry move. Most images were moved to
registry.developers.crunchydata.com, which requires authentication and acceptance of terms before pulling. That draws a clearer line between open-source code and proprietary builds.
In other words: the project is open source on the code side, but the practical artifacts (images, helm releases) are gated.
What these restrictions really mean for Kubernetes users
When container images and operators come with redistribution limits, authentication requirements, or "internal-use-only" clauses, the impact on Kubernetes environments is immediate and concrete. Teams can no longer:
- Build air-gapped clusters by mirroring images to a private registry without working through a license review
- Rely on GitOps workflows that assume publicly accessible OCI images
- Fork or customize the operator freely, because official images cannot be redistributed with modifications
- Use the software in commercial or customer-facing products without additional licensing
- Run multi-cluster or multi-tenant Postgres at scale without bumping into usage terms
For a database operator, where almost every operational pattern depends on the container images you can pull and run, these restrictions effectively turn a project into a "source-available but not operationally open" solution. The code is open. The operating story is not.
As a result, many teams are switching to fully open-source alternatives: the Percona Operator for PostgreSQL, CloudNativePG, Zalando Postgres Operator, StackGres, and a few others.
How to evaluate "open source" in 2026
The bigger picture here is that "open source" today often exists more in theory than in practice. It pays to look past the badge and check the operating reality. Three questions to ask before you commit to an operator:
1. Are the container images publicly redistributable?
If you cannot pull the official images without authentication, or you cannot mirror them to your private registry without a license review, your air-gapped and GitOps stories are constrained from day one. This is the question that turned out to be the most consequential one for MinIO, Bitnami, and Crunchy users in 2025.
2. Are core operational features in the open-source build, or behind a paywall?
Backup, monitoring, HA, and security features should be in the build everyone uses, not gated behind an enterprise tier. A "community edition" that omits the feature most teams actually need is a marketing build, not a real open-source build.
3. Is the governance and roadmap public?
A project where you can see the issues, the PRs, and the roadmap is one you can plan around. The Percona PG Operator's public roadmap is an example of what this looks like in practice. A project run inside a vendor's private tracker, by contrast, gives you no visibility.
These are not gotchas. They are the questions that decide whether a project will still serve you the same way in three years.
Migrate to freedom
Announcing the hard fork
We strongly believe in fully open-source software and want to increase our investment in the PostgreSQL and Kubernetes ecosystems. To back that up, we have decided to hard fork the Crunchy Data PostgreSQL Kubernetes Operator. Starting from version 3.0.0, the Percona PostgreSQL Kubernetes Operator is a fully independent project, with a public roadmap, public issue tracker, and freely redistributable images.
The hard fork is not a critique of Crunchy's engineering. It is a commitment that the operator will keep evolving in a fully open-source direction, with no surprises about which features will be available to which audience.
Why migration is straightforward
Because the Percona PostgreSQL Operator is a hard fork of the Crunchy operator, the migration paths are surprisingly straightforward. The same underlying tools (Patroni, pgBackRest, PgBouncer) and the same overall design are used in both, which means migration can be done in multiple ways, sometimes with near-zero downtime, sometimes faster with a small downtime window. The next two posts in this series walk through three concrete options.
What's next
This was the "why." The next two posts are the "how":
- Part 2: Standby cluster migration. Bring up a Percona cluster as a standby of the Crunchy primary, catch it up via pgBackRest plus streaming replication, and promote it at cutover. The only downtime is the cutover itself.
- Part 3: Backup-restore and PV reuse. Two simpler paths: bootstrap a Percona cluster directly from a Crunchy pgBackRest backup, or retain the existing PGDATA persistent volume and have Percona pick up where Crunchy left off.
Reversibility and exit options
All three paths are reversible: because Percona's operator, images, and tooling are 100 percent open source and remain compatible with the same backup format and the same Patroni HA model, you keep full control. You can migrate back to Crunchy if your team decides to, or out to another open-source operator (CloudNativePG, Zalando, StackGres) using the same patterns. That last journey is a topic for a future article.
This series covers basic deployment patterns and simplified configuration examples. If your environment is more complex, uses custom images, includes Crunchy enterprise features like TDE, or otherwise needs tailored migration steps, contact the Percona team and we will help you plan and execute the move.
This post was originally published on the Percona blog. For the full Try It Out links (Percona PostgreSQL Operator docs, GitHub, public roadmap, issue tracker, community forum), see the bottom of the canonical post.