Empowering Kubernetes: Percona Redefines Trust with Community PostgreSQL Images

In the rapidly evolving ecosystem of Kubernetes-native databases, a silent crisis has been brewing. While the open-source movement championed the freedom of source code, a new trend of "artifact gatekeeping" has emerged, where vendors maintain open source repositories while locking the production-critical elements—container images, optimized builds, and deployment configurations—behind proprietary walls.

With the launch of the Percona Operator for PostgreSQL (PGO) 3.0.0, Percona is taking a bold, corrective step. By introducing "Community PostgreSQL Images," the company is shifting the power dynamic back to the user, providing a transparent, vendor-agnostic path for running production-grade PostgreSQL on Kubernetes.

Main Facts: Restoring Sovereignty to the Data Layer

The core challenge for any Kubernetes database administrator is trust. When you deploy a database operator, you are essentially outsourcing your infrastructure’s stability to two entities: the code itself and the container images that the operator pulls from remote registries.

While the source code for most operators is readily available on platforms like GitHub—allowing for inspection and forking—the container images are often managed exclusively by vendors. This creates a hidden dependency. A vendor can modify an image’s contents, change its registry access, or alter the underlying distribution terms without ever touching the source code.

PGO 3.0.0 eliminates this "black box" dependency by allowing users to run the operator against images they build themselves, derived from official PostgreSQL packages sourced directly from download.postgresql.org. By shifting the control of the container registry and the image build process to the user, Percona is effectively removing the vendor-imposed lock-in that has characterized much of the recent enterprise database landscape.

Chronology: The Evolution of Vendor-Driven Distributions

The shift toward restrictive artifact management did not happen overnight. To understand the significance of PGO 3.0.0, we must look at the recent history of the open-source database market:

• The Era of Open Core: For years, companies operated under the "Open Core" model, where the engine remained free while enterprise-grade management tools were paid. This was generally accepted by the community.
• The Shift to "Closed Artifacts": In recent years, vendors discovered that they could keep the source code "open" to satisfy legal requirements while effectively locking users into their ecosystem by controlling the distribution artifacts. This included proprietary container images, specialized Kubernetes distributions, and exclusive marketplace listings.
• The PostgreSQL Operator Backlash: The PostgreSQL community, known for its high standards and independence, began to voice concerns as various operators started moving features behind proprietary paywalls or restricting the use of their pre-built images.
• The Percona Pivot: Recognizing the growing skepticism and the rational fear of vendor-driven lock-in, Percona began a strategic shift. Starting with version 3.0.0, they moved to fully decouple their operator from their specific image distribution, signaling a commitment to a "trust but verify" model.

Supporting Data: Understanding the "Community Image" Architecture

The PGO 3.0.0 architecture is designed for transparency. The operator is now "registry-agnostic," meaning it no longer mandates the use of Percona-provided images. Instead, it expects a standard runtime environment that the user can verify, build, and maintain.

The Image Composition

The community images are structured as thin, lightweight layers built upon stable bases like Red Hat’s Universal Base Image (UBI8 or UBI9). Each image is purpose-built for its role within the cluster:

• Postgres Image: Includes the core server, contrib modules, and essential extensions such as pg_repack, pgaudit, pgvector (for AI/ML workloads), and pg_cron.
• pgBackRest Image: A specialized, minimal image dedicated exclusively to high-performance backup and recovery operations.
• pgBouncer Image: A lean, high-concurrency connection pooler designed to optimize application-to-database communication.

By splitting these components into separate failure domains, Percona has not only increased reliability but also significantly reduced the attack surface of each container.

Building and Deploying

Percona provides the Dockerfile and the necessary build scripts within the percona-docker GitHub repository. The build process uses standard docker buildx targets, allowing teams to integrate these images into their own internal CI/CD pipelines.

# Example: Building the community images for your own registry
make all TAG=1.0.0 REGISTRY=myrepo/percona-postgresql-operator

This command builds the entire suite—Postgres, pgBouncer, and pgBackRest—ensuring they remain version-aligned and ready for deployment via a standard custom resource (CR) file.

Official Responses: Why Transparency is a Competitive Advantage

Percona’s leadership frames this move not as a charity, but as a strategic necessity. "The skepticism is fair," notes the engineering team behind the operator. By acknowledging that distributions offer real value—such as pre-tested extension matrices and optimized security patches—Percona argues that the goal is not to eliminate distributions, but to offer a transparent alternative.

The company admits that running your own images comes with a trade-off: the responsibility of image maintenance, security scanning, and updates rests with the user. However, for large enterprises and highly regulated industries, this trade-off is often preferred. The ability to audit exactly what goes into the container is a requirement for compliance, not just a preference.

"We are not forcing users to build their own," the team explains. "We are simply opening the door. If the community finds value in this path, we will continue to invest in the tooling to make it easier. If not, the signal is clear."

Implications: The Future of Database Operations

The introduction of Community PostgreSQL Images in PGO 3.0.0 has profound implications for the Kubernetes and PostgreSQL communities:

1. The Death of Forced Lock-in

By decoupling the operator logic from the image registry, Percona has effectively neutralized the "image-host" leverage that vendors often use to enforce product roadmaps. Users now have the technical capability to maintain their infrastructure even if the vendor changes their licensing or distribution strategy.

2. Community-Driven Extension Support

One of the most immediate benefits is the acceleration of extension support. In the past, if an organization needed a niche extension like TimescaleDB or Citus, they were dependent on the vendor’s roadmap. Now, the community can contribute these extensions directly to the community image build process, bypassing the traditional "vendor-approval" cycle.

3. A New Standard for "Open Source"

This move sets a high bar for other database operators in the CNCF landscape. It challenges the industry to define what "Open Source" truly means in a cloud-native world: does it mean the code is visible, or does it mean the entire lifecycle of the product—from build to deployment—is in the hands of the user?

4. Security and Compliance

For organizations in the financial, healthcare, or government sectors, the ability to build images from upstream sources while maintaining the robust orchestration of a top-tier operator is a game-changer. It allows for "known-good" builds that pass strict internal security audits without requiring a vendor’s digital signature.

Conclusion: A Call for Active Participation

The release of Percona Operator for PostgreSQL 3.0.0 is a significant milestone that honors the original spirit of open-source software. By providing the tools for users to build, secure, and manage their own production images, Percona is fostering a healthier, more resilient ecosystem.

As the industry continues to debate the ethics of vendor-controlled artifacts, Percona has chosen a clear path: empowering the user. Whether this leads to a massive migration toward self-built images or remains a powerful tool for those with specific compliance needs, one thing is certain: the conversation around "what constitutes open source" has been fundamentally altered.

Users are encouraged to explore the tech preview in version 3.0.0, participate in the GitHub discussions, and provide feedback on the build flows. As Percona moves toward the official 3.1.0 release, the evolution of these community images will be guided by the very community they serve. The door is open; it is now up to the practitioners to walk through it and shape the future of their data infrastructure.