iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
You can run a database inside Kubernetes: the database process, its persistent storage resources, and its lifecycle management are part of the cluster. That can give a team control over configuration and integration, but it also makes the team responsible for database operations, storage validation, backups, and recovery. If those responsibilities do not fit your skills or requirements, a database hosted outside the cluster may be the better choice.
What does it mean to run a database on Kubernetes?
A database running on Kubernetes is more than an application Pod that happens to connect to a database service. In an in-cluster design, Kubernetes schedules the database process, and cluster-managed storage resources hold its data. A database-aware operator can also manage database-specific tasks such as provisioning instances, coordinating replication, and responding to failures.
PostgreSQL with CloudNativePG is one documented example. CloudNativePG represents a PostgreSQL cluster with a custom Cluster resource and manages persistent volume claims (PVCs) directly; its version 1.25 documentation says it does not use StatefulSets for data persistence. The operator coordinates PostgreSQL roles and Kubernetes resources, but it does not make storage durable by itself or remove the need for database expertise. CloudNativePG 1.25 documentation
Free tools Windows power users keep installed
One-click scans. No signup required.
By contrast, when an application in Kubernetes connects to a database service hosted elsewhere, that database remains an external dependency. The application may still use Kubernetes service discovery or secrets to connect, but the database’s compute and data lifecycle are not running inside the cluster.
#1 Best Overall
Should you run the database inside the cluster or beside it?
Choose based on the operational ownership you can sustain, the control your application needs, and whether your storage and recovery design meet its requirements. Neither placement is a universal cost or performance winner: those outcomes depend on workload, infrastructure, and comparable service assumptions.
| Decision area | Database inside Kubernetes | Database outside Kubernetes |
|---|---|---|
| Operational ownership | Your team operates the database and Kubernetes integration. An operator can automate declared lifecycle procedures, but still requires database and Kubernetes expertise. | Ownership depends on the external service and support arrangement; establish who handles upgrades, failover, monitoring, backups, and restores. |
| Configuration and topology | Useful when you need control over configuration, extensions, or deployment architecture. Microsoft identifies these as reasons to host PostgreSQL on AKS. Microsoft’s AKS PostgreSQL overview | Evaluate whether the available service supports the configuration and topology your workload requires. |
| Storage and failure behavior | You select and validate the storage class, persistence guarantees, performance, and failure behavior for the workload. | Understand the external provider’s storage and availability design; it remains a separate dependency for cluster workloads. |
| Application connectivity | An operator can expose services for client connections and update routing when the primary role changes. CloudNativePG documents services for application access. CloudNativePG 1.25 documentation | Configure application networking and credentials for the external endpoint. |
| Recovery responsibility | Define backup location, retention, recovery objectives, and restore procedure; replica count alone does not define recovery. | Confirm what backup and restore capabilities are included and who is accountable for exercising them. |
An in-cluster design is most defensible when the team needs that control and has the capacity to operate the full data lifecycle. An external database is often a better fit when the team wants to keep database operations separate from cluster operations or cannot validate and support the in-cluster storage and recovery path.
What does an operator automate—and what remains yours?
A database operator encodes database-aware procedures in Kubernetes resources and automation. In CloudNativePG’s PostgreSQL design, the operator integrates with the Kubernetes API to manage primary and standby roles, streaming replication, and client services. CloudNativePG project overview CloudNativePG architecture documentation
This differs from relying on generic workload primitives alone: the operator understands database roles and lifecycle actions. But automation is not a substitute for a recovery plan or operational ownership. Your team still needs to choose compatible versions, set resource and storage expectations, monitor the database, plan changes, and know how to restore service when automation is insufficient.
Rank #3
How should you design storage and durability?
For a database, a PVC is not a durability strategy by itself. Verify that the chosen storage and CSI provider meet the workload’s latency, throughput, capacity, attachment, expansion, and failure-recovery needs. CloudNativePG’s storage guidance recommends benchmarking in a controlled Kubernetes environment before production and warns that pre-provisioned volumes can affect its high-availability and self-healing behavior. Those recommendations concern its documented approach; confirm them against the operator version and storage provider you deploy. CloudNativePG storage guidance
- Test the actual storage path. Benchmark with a representative workload in a controlled environment rather than assuming a storage-class label guarantees database performance.
- Understand what happens to data during node events. Microsoft’s AKS guide notes that data on local ephemeral disks can be lost when the hosting VM or node is stopped or deallocated. It demonstrates periodic backups to Azure Blob Storage as a separate recovery route. This is an AKS-specific example, not a claim about every local disk or CSI driver. Microsoft’s AKS PostgreSQL overview
- Keep provider examples provider-specific. Google’s GKE tutorial recommends the
premium-rwostorage class for its SSD-backed example; that is not a general Kubernetes requirement. Google Cloud’s GKE CloudNativePG tutorial
How do replicas, failover, and backups fit together?
Replicas and failover address availability: a database-aware system can promote or route to another instance when the primary is unavailable. Backups address recovery from events that replication may reproduce or fail to protect against. These are different protections, so replica count does not establish a recovery point objective (RPO) or recovery time objective (RTO).
CloudNativePG documents PostgreSQL streaming replication and continuous backup with point-in-time recovery. Cloud examples store backup data in separate object storage, including Google Cloud Storage and Azure Blob Storage. Keep backups away from the primary database storage, set retention to match your needs, and decide what failures replicas cover versus those that require a restore. CloudNativePG project overview Google Cloud’s GKE CloudNativePG tutorial Microsoft’s AKS PostgreSQL overview
Multi-zone examples in the GKE and AKS guides show how placement can distribute instances across availability zones, but their topologies and storage behavior are provider-specific. Storage-level replication is also not the same as PostgreSQL-level replication or an independent backup. Do not promise zero downtime or zero data loss without deployment-specific evidence.
Quick Recap
Best Value
What is a practical deployment sequence?
- Choose the database and operating model. For PostgreSQL, decide whether your team has the Kubernetes and database skills to use an operator. CloudNativePG is one documented option, not the only possible choice. CloudNativePG project overview EnterpriseDB supported CloudNativePG documentation
- Set topology and failure domains. Decide the instance count and placement based on availability needs, zone design, and available cluster resources. Treat the GKE and AKS multi-zone examples as illustrations for those environments, not copy-and-paste universal designs. Google Cloud’s GKE CloudNativePG tutorial Microsoft’s AKS PostgreSQL overview
- Select and validate persistent storage. Confirm durability, attachment behavior, performance, expansion, scheduling constraints, and failure recovery with the storage provider and chosen operator. Benchmark before production. CloudNativePG storage guidance
- Configure connectivity and security. Plan application endpoints, credentials, and encryption according to your environment’s security model. The GKE tutorial demonstrates operator-managed services and TLS-related resources; do not copy example secrets into production. Google Cloud’s GKE CloudNativePG tutorial
- Set backup and recovery objectives. Choose backup storage separate from the primary database storage, define retention, and state the RPO and RTO you need. Confirm that your selected backup method can support those objectives.
- Exercise restore and failover. Document the procedures and test them before relying on them. A feature described in documentation is not evidence that a particular deployment has successfully recovered.
- Add monitoring and plan upgrades. Decide how to observe database health and capacity, and plan version changes against compatibility requirements. The GKE tutorial includes a Prometheus exporter path and rolling minor PostgreSQL updates; treat upgrade behavior as version-specific. Google Cloud’s GKE CloudNativePG tutorial
What should you verify before production?
- The team has named owners for database upgrades, failover, monitoring, backup, and restore.
- Storage has been benchmarked against a representative workload, and node, volume, and zone failure behavior is understood.
- Backups are stored separately from the primary database storage, with retention and recovery objectives defined.
- A restore and a failover have been exercised and documented for the actual deployment.
- Application connectivity, credentials, encryption, monitoring, and version compatibility have been checked for the deployed operator and database versions.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
