More and more people are looking into running stateful applications like databases on Kubernetes, and for good reason. Our recent hands-on workshop on running PostgreSQL on Kubernetes was fully booked, so it’s clearly a hot topic. But why is this combination suddenly so popular, and what does it take to get it right?

To answer these questions, we sat down with two experts: Guy Gyles, our own Senior DBA and Tech Lead, and Dennis Grigaliunas, Technical Sales Engineer at our partner Piros, who specialize in open-source systems like OpenShift. Let’s dive in!

For a long time, running a database in a containerized environment didn’t really work. “Databases need to store data persistently,” Guy explains. “Unlike a stateless application, you can’t shut them down and spin them up without a thought. The technology just wasn’t mature enough for production workloads.”

That has changed dramatically. The evolution of Kubernetes (and that of operators in particular) has made it possible for enterprises to run databases without having to compromise on reliability and performance.

As we pointed out above, the operator functionality is the key to running databases on Kubernetes. Think of it as a highly skilled robot DBA that is part of your cluster. Our preferred choice is CloudNativePG, an open-source operator originally created by our enterprise partner EDB.

“However, you don’t have to give an operator a list of step-by-step commands,” Guy points out. “Instead, you provide a blueprint of your production-ready PostgreSQL setup in a YAML file, and the operator will take care of the rest.”

But it doesn’t stop there. The operator’s most crucial job is to make sure the environment stays in that perfect state. Guy continues: “If the primary database has an issue, the operator automatically manages the fail-over to a replica, often in under a minute. The end-user might notice a brief pause, but there’s no data loss and minimal downtime.”

Running a test database is one thing, but running a “production-ready” cluster has to handle the real world. And that means demanding SLAs, security threats, and the absolute need for reliability.

For business-critical applications, especially in sectors like finance or healthcare, this requires a specific setup. “You can’t afford to lose a single transaction,” Guy states. “This means you need synchronous replication and a cluster with at least three nodes (one primary, two replicas). If the primary fails, a fully up-to-date replica is ready to take over with zero data loss.”

But a solid architecture is only half the story. The other pillar of a production-ready system is enterprise-grade support. “You can’t wait on community forums for a patch when a critical bug hits your production environment,” Dennis emphasizes. “For real SLAs, you need an expert partner to call.”

That’s precisely why we suggest combining an enterprise platform like Red Hat OpenShift with an enterprise-supported database like EDB Postgres. It gives you the assurance that your entire stack is supported, from the infrastructure all the way up to the database.

With all this automation, you might be wondering: is the DBA out of a job?

“Not at all,” Guy explains. “The role is evolving, just as it always has. Repetitive tasks are being automated, which is a good thing! It lets the DBA focus on higher-value work. An operator can’t magically fix a poorly written query or design a database schema, so core database knowledge is more important than ever.

In fact, the biggest challenges teams face are often human, not technical. “The knowledge gap for Kubernetes is still significant,” Dennis admits. “And sometimes, a company’s internal culture is the biggest blocker. You need to promote a DevOps mindset where system engineers, developers, and DBAs work together. If those teams weren’t collaborating well before, this transition won’t suddenly make everything work.”

This new way of working is exactly why the partnership between Zebanza and Piros makes so much sense. “We’re two sides of the same open-source coin,” says Dennis. “We provide cloud-ready systems like OpenShift for applications to run on, but those applications need powerful databases.”

Guy agrees: “We know databases inside and out, but a database can’t run on thin air. It needs a solid, well-configured infrastructure. By working together, we can design and deliver a complete, end-to-end solution for our customers.”

If you’re considering making the move to PostgreSQL on Kubernetes, the best advice from both Guy and Dennis is simple: do your homework, but don’t wait too long.

“Get to know the concepts before you dive in,” advises Guy. Dennis adds, “And be open to embracing this new technology. Containerization is the direction the industry is heading. Sooner or later, your most important applications will be delivered this way, and you’ll need to be ready.”