If you are using Kubernetes for a new development project, launching an application modernization effort, or engaging in digital transformation, chances are you need a database and Postgres may be the answer.
Kubernetes provides many benefits for running applications, including efficiency, automation, and infrastructure abstraction. These advantages continue to drive organizations to standardize application deployments on Kubernetes. However, there is still a common question as to whether Kubernetes is “ready” for databases.
With a mature Kubernetes operator in PGO and a new option to run Crunchy Bridge with a Kubernetes operator, you have great choices.
So which deployment model is appropriate for you? As usual, it depends.
Postgres Operator: Self-Managed Postgres on Kubernetes
The Kubernetes features that make it a great application platform can also be used to help you deploy highly available databases and scale, making it easier to manage hardware for databases as they grow.
When coupled with an operator, Kubernetes can provide database-specific tooling to enable you to scale up nodes uniformly, which also helps with managing hardware for databases as they grow. Kubernetes features like node affinity, tolerations, and pod topology spread constraints allow admins to make decisions about where Postgres instances are deployed.
These tools combine to enable database workloads to benefit from high availability or specific hardware. The maturation of these capabilities around these databases and the potential for declarative and GitOps-friendly workflows motivated much of PGO v5, the open source Postgres operator from Crunchy Data.
As a result, more users are adopting databases natively on Kubernetes. The Cloud Native Computing Foundation (CNCF) provides great data on Kubernetes adoption. Its Cloud Native Survey 2020 shows that 55% of its respondents are using stateful applications in containers in production. Crunchy Data has many customers who successfully run Postgres on Kubernetes.
Operators and tools such as Helm and Kustomize are all helpful in easing the administrative burden, but automation and orchestration associated with Kubernetes do not come for free.
Despite the benefits of automation, running databases natively on Kubernetes still requires you to run your database and has been described as “closer to the full-ops option.” Running Kubernetes, and applications on Kubernetes, comes with its share of administrative requirements.
In the context of Postgres, the question seems to boil down to whether a user values the benefits of Kubernetes sufficiently to sustain the incremental administration.
Fully Managed Postgres for Kubernetes
What about fully managed database options for Postgres?
Managed services are an attractive option for deploying databases, enabling the managed service provider to handle a number of the database administration tasks for you — including backups, patching, and scaling.
The combination of a Kubernetes operator plus a managed database service provides you with the ability to maintain your Kubernetes standardized workflows while benefiting from third-party, hands-on expertise for database management. By using a “cloud agnostic” managed database service like Crunchy Bridge, you receive the benefit of fully managed Postgres from engineers with decades of experience running large-scale Postgres databases and database-as-a-service on your choice of cloud provider.
We are proud to have partnered with Red Hat to help simplify access to database services on Kubernetes through the new service, Red Hat OpenShift Database Access (RHODA).
For users who are not interested in maintaining a database server, managed Postgres is a great option.
So, What Should You Do?
Good news! Deciding to use Postgres is a great start; we like to think it’s the right start. There are several options on how best to deploy it.
Doing so is less of an either/or decision and more of a when and where question. Similar to the hybrid cloud reality that enterprises of all sizes tend to use, Postgres users often choose a combination of these deployment models based on their team’s requirements and organizational standards.
The choice boils down to which model to use for a given project rather than which model to use for all applications.
For on-premises users, or users who require more hands-on deployments, Kubernetes native Postgres with a Postgres operator is a great option. For many projects, using a managed service works well if the use cases require a “set and forget” Postgres deployment.
As with everything, each decision has trade-offs, but as long as you start with “the answer is Postgres,” it is unlikely you’ll get too far off the correct path. If you need help, Crunchy Data is here to assist.
Red Hat is a sponsor of InApps Technology.
