Three Cloud‑Native Approaches to Deploying PostgreSQL: CloudNativePG, Korifi, and Neon

PostgreSQL has solidified its position as one of the most popular databases worldwide, ranking fourth in Statista. According to the 2023 PostgreSQL State of the DB Survey, its adoption rate is stable and accelerating. Since its first release in 1990, methods for installing, deploying, and managing PostgreSQL have evolved.

This article explores three cloud‑native and open‑source ways to deploy PostgreSQL.

Using CloudNativePG on Kubernetes

In today’s cloud‑native environment, deploying PostgreSQL on Kubernetes is an obvious choice. Helm charts simplify the deployment, but they cannot handle post‑deployment operations for stateful workloads such as scaling, backup, failover, and upgrades. This is where Kubernetes operators come into play.

CloudNativePG is an open‑source Kubernetes operator praised for its robustness and vendor‑neutral backing. Two years ago, the company behind the project, EDB, donated its IP to the community.

Compared with other operators like Crunchy Data and Zalando, CloudNativePG emphasizes simplicity and data security. A standout feature is its focus on data integrity and high availability, supporting synchronous replication and automated failover to keep data consistent and accessible even when a node fails.

Using Korifi for self‑service

The rise of platform engineering has increased demand for self‑service capabilities, allowing developers to deploy and manage services without relying on operations teams. Cloud Foundry has long been a pioneer in providing a developer‑centric PaaS experience.

Korifi offers the same developer experience as Cloud Foundry but runs on Kubernetes instead of VMs. It abstracts Kubernetes complexity, giving developers a familiar, seamless interface.

Its key historical feature is the addition of the Cloud Foundry Marketplace, where operators and developers can deploy pre‑built applications and services, including PostgreSQL, with a simple cf create-service postgresql command.

Using Neon to separate compute and storage

Traditional PostgreSQL deployments couple compute and storage, limiting scalability and causing resource waste. Neon provides a serverless approach that separates storage and compute for easier use.

As a serverless alternative to AWS Aurora PostgreSQL, Neon replaces the standard storage layer with a distributed architecture that shards data across a node cluster. This separation allows independent scaling of compute and storage, optimizing performance and cost.

One of Neon’s most popular features is instant database cloning and branching, similar to Git’s handling of code branches, enabling development teams to quickly create isolated database instances.

Conclusion

Although this article does not exhaustively list modern PostgreSQL deployment methods, the discussed approaches reflect three important trends.

First, infrastructure is shifting toward cloud‑native principles. Running stateful workloads on Kubernetes, once considered impractical, is now standard and requires operators to handle extra tasks.

Second, the demand for self‑service solutions that align with platform‑engineering principles continues to grow, empowering developers to configure and manage resources independently.

Finally, driven by cost, compliance, and security considerations, more enterprises are moving away from managed services toward open‑source or private SaaS solutions that provide the same functionality while giving full control over their data.