How Do You Run PostgreSQL on Kubernetes Safely?

Running PostgreSQL on Kubernetes is possible, but it is not the same as running a stateless web service. PostgreSQL has persistence, failover, backup, replication, and recovery requirements that need to be designed deliberately. If those pieces are handled casually, the cluster may deploy the database successfully but still fail to operate it safely in production.

That is why “PostgreSQL on Kubernetes” is not just a deployment question. It is an architecture question. You need to think about storage durability, backup strategy, failover behavior, upgrade sequencing, resource limits, and how the database will behave when pods or nodes are replaced.

This article explains the risks of running PostgreSQL on Kubernetes, the standard approaches teams use, their limitations, and how to build a production-ready model across Kubernetes and k3s.

The Problem: Databases Are Stateful and Kubernetes Is Dynamic

Kubernetes is designed to schedule and recover workloads dynamically.

PostgreSQL is designed to preserve data safely and maintain consistency.

Those two goals can work together, but they do not solve the same problems.

Why this is hard

In a typical Kubernetes environment, pods are expected to move, restart, and be replaced. For PostgreSQL, that is only safe if:

• The data volume survives pod rescheduling
• The database comes back cleanly after failure
• Replication or failover is configured correctly
• Backups are reliable and tested
• Storage latency stays within acceptable limits

If any of those pieces are missing, the database may start, but the platform may not be able to recover it safely after an incident.

The difference between deployable and operable

A manifest that creates a PostgreSQL pod is not enough.

To run PostgreSQL safely, you need:

• Persistent storage
• Correct shutdown and startup behavior
• A recovery plan
• A backup and restore workflow
• A clear upgrade process

That is what makes database operations different from ordinary Kubernetes workloads.

What PostgreSQL Needs in Production

PostgreSQL is reliable when it is treated like a stateful system.

1. Durable storage

The database files must live on persistent volumes with a storage class that matches the performance and durability requirements of the workload.

2. Predictable resource sizing

CPU and memory requests need to reflect actual workload behavior.

If PostgreSQL is underprovisioned, you may see:

• Slow queries
• Memory pressure
• Poor checkpoint behavior
• Unstable performance under load

3. Backup and restore

You need more than a backup job. You need a tested restore process.

4. Failover or recovery planning

If the primary pod or node fails, the database must either fail over or recover cleanly.

5. Upgrade sequencing

PostgreSQL version upgrades and schema migrations must be coordinated carefully.

Current Industry Standard Approaches

Most teams use one of three patterns.

1. Managed database outside Kubernetes

Many organizations keep PostgreSQL outside the cluster entirely.

This is the simplest operationally because the cloud provider or database platform handles:

• Storage durability
• Backups
• High availability
• Patching

This is a good option when the team wants to reduce operational burden.

2. PostgreSQL on Kubernetes with an operator

This is the common approach when teams want the database inside the Kubernetes control model.

Operators such as these are often used:

• CloudNativePG
• Crunchy Data PostgreSQL Operator
• Zalando Postgres Operator

These operators help automate:

• Initialization
• Replication
• Failover
• Backup jobs
• Rolling updates

3. PostgreSQL on Kubernetes as a single StatefulSet

Some teams deploy PostgreSQL with a StatefulSet and manage failover and backups more manually.

This can work for simpler environments, but it places more responsibility on the platform team.

What Good PostgreSQL on Kubernetes Looks Like

If PostgreSQL is going to run in Kubernetes, the production setup should be explicit about the database’s operating model.

1. Use persistent volumes with the right storage class

Storage is the foundation of safety.

The storage backend must match the workload’s durability and latency needs.

2. Separate data from the pod lifecycle

The pod may be replaced, but the data must remain intact.

3. Use readiness and startup probes carefully

The database should only receive traffic when it is actually ready.

4. Define resource requests and limits

This helps the scheduler place the workload correctly and keeps node pressure predictable.

5. Plan backups and restore drills

Backups are only useful if restore has been tested.

6. Decide how failover works

If there is a primary and replica model, the team must know how promotion happens.

7. Coordinate upgrades

Database upgrades should be planned, tested, and version-aware.

Limitations and Tradeoffs

Running PostgreSQL on Kubernetes is not always the best answer for every team.

It adds operational complexity

You now own:

• Storage behavior
• Replication behavior
• Operator lifecycle
• Backup automation
• Scheduling and placement

It can hide storage problems

If the cluster storage layer is slow or unstable, the database will suffer even if the pod is healthy.

Failover needs careful testing

Automatic failover is useful, but it must be tested under real conditions.

Not every workload benefits from moving the database into the cluster

For some teams, an external managed database is still the cleaner choice.

A Better Solution Approach

The right model depends on the team’s operational maturity and the workload’s criticality.

Use a managed database when you want lower overhead

This is often the simplest and safest path for smaller teams.

Use an operator when you need Kubernetes-native control

This gives you a more automated and declarative PostgreSQL experience inside the cluster.

Use strong storage and restore discipline regardless of the model

Backups, restore tests, and resource sizing matter either way.

Treat PostgreSQL as a platform component

It should have its own runbook, ownership, and monitoring posture.

How NebuaCloud Fits Into This Model

This is where NebuaCloud fits naturally.

NebuaCloud is focused on Kubernetes management, GitOps workflows, multi-tenant infrastructure, and simplified deployment of production workloads. In a PostgreSQL-on-Kubernetes setup, that means the platform can help teams manage the surrounding operational concerns more consistently instead of treating the database as a one-off exception.

What this means in practice

NebuaCloud can help teams:

• Manage Kubernetes and k3s clusters that host stateful workloads
• Apply GitOps workflows to PostgreSQL manifests and operator configuration
• Support multi-tenant infrastructure with clearer boundaries around database workloads
• Use observability signals to detect storage pressure, rollout issues, or unhealthy replicas earlier
• Simplify production workload deployment while keeping database operations visible

That is useful when PostgreSQL needs to be part of a repeatable production platform, not just a manually managed StatefulSet.

Practical Example: Running PostgreSQL with an Operator

Imagine a team using PostgreSQL for a customer-facing application.

Deployment flow

1. The team provisions a Kubernetes cluster with reliable storage.
2. They install a PostgreSQL operator.
3. The database manifest defines the primary, replicas, and storage requirements.
4. Backups are configured to run automatically.
5. Readiness probes ensure traffic only reaches healthy database pods.
6. Resource requests and limits are set according to workload size.
7. Restore drills are tested before production rollout.

Why this is safer

The operator handles much of the repetitive database lifecycle, while the platform team remains responsible for storage, recovery, and observability.

Conclusion

Running PostgreSQL on Kubernetes safely is possible, but it requires more than deploying a container and attaching a volume. You need durable storage, tested backups, careful failover planning, resource sizing, and an operating model that treats the database as a critical stateful service.

For teams running Kubernetes and k3s in production, NebuaCloud can provide a natural operational layer for GitOps, observability, and multi-tenant infrastructure so PostgreSQL workloads stay easier to manage safely.

Try it with NebuaCloud -> deploy in minutes

Current Availability

NebuaCloud already has real building blocks around this topic in the current codebase, including database deployment paths, PostgreSQL-related parameters, persistent storage configuration, database visibility in the dashboard, and cluster-level backup and restore primitives.

At the same time, the full PostgreSQL operating model described in this article, especially around operator-driven failover, automated replica management, and a complete database safety workflow, is not yet exposed as a finished end-to-end NebuaCloud product capability today. Where those features are not directly available, they should be understood as future platform direction rather than current complete functionality.