EDB Postgres AI for CloudNativePG Reviews & Product Details

I like the feature where we can build Gen AI application directly on EDB Postgres AI for CloudNativePG. The scaling of AI models within the database is another aspect I appreciate. The Unified workloads feature, allowing for both traditional transactional queries and AI tasks on the same platform, stands out to me. Additionally, I like the hybrid data manager feature. With these capabilities, it's useful for handling growing chatbot data and supports vector search, which is widely used for AI applications. Review collected by and hosted on G2.com.

It's very difficult to create initial setup and configuration database for AI workloads due to improper documentation, so I'd like to improve the document's content. There are some advanced features in EDB, but due to lack of documentation, we are not aware of how to use them. The PostgreSQL uses one primary writer node with multiple read replicas which becomes a bottleneck for very high write workloads. It should follow similar to Google Spanner so that we scale horizontally. It's very hard to set up initially without any expert in PostgreSQL. The challenge we faced is how to configure replications and containers, and it's very difficult to configure security as well. Review collected by and hosted on G2.com.

I use EDB Postgres AI for CloudNativePG to manage my PostgreSQL databases on Kubernetes effortlessly. It automates cluster deployment, scaling, backups, and failover, which reduces my manual effort significantly. I like how much it simplifies running PostgreSQL in Kubernetes, and the automation saves me a lot of time. The high-availability features are a big plus, providing reliability and confidence in production. The declarative configuration integrates smoothly with GitOps workflows, making operations more predictable and consistent. Overall, it's well-suited for production Kubernetes environments. Review collected by and hosted on G2.com.

One thing that could be improved with EDB Postgres AI for CloudNativePG is the learning curve — it can feel complex at first if you’re new to Kubernetes operators. Some advanced operations and version upgrades also require careful planning, which can add overhead. Simplifying documentation and easing major PostgreSQL version upgrades would make the experience even better. Review collected by and hosted on G2.com.

I like the strong integration with Kubernetes and the automation it provides for managing PostgreSQL clusters. The automated failover and high availability features give us confidence that our databases remain stable even during node failures. Another standout aspect is the intelligent performance insights. The AI-driven recommendations help identify slow queries and configuration improvements, which reduces the time spent on manual troubleshooting. I also appreciate the declarative configuration model, which aligns well with DevOps practices and infrastructure-as-code workflows. It makes deployments more consistent and easier to manage across environments. Overall, the combination of enterprise-grade reliability with cloud-native flexibility is what stands out the most. Review collected by and hosted on G2.com.

While the overall experience has been positive, there are a few areas that could be improved. The initial setup and advanced configuration can feel complex, especially for teams that are new to Kubernetes or CloudNativePG. Some scenarios require deeper understanding of PostgreSQL internals and cluster architecture. Additionally, clearer documentation for certain advanced use cases and tuning parameters would be helpful. Although the documentation is generally good, more practical examples or real-world deployment guides would make onboarding easier. Improved visibility into pricing tiers and feature differences would also help teams plan better before adopting it at scale. Review collected by and hosted on G2.com.

1) Kubernetes-native design with Cloud Native PG.

2) Enterprise-grade PostgreSQL capabilities backed by EnterpriseDB.

3) Strong alignment between AI initiatives and the data platform.

4) Operational simplicity that makes day-to-day work easier for DevOps teams. Review collected by and hosted on G2.com.

1. Complexity for Smaller Teams

While powerful, this stack can feel heavy for small development teams, simple apps without strict SLAs, or projects that don’t need fully Kubernetes-native database operations. In those cases, some teams end up spending more time on configuration and platform work than on building application features.

2. Steeper Learning Curve

Because it blends PostgreSQL internals, Kubernetes operators and CRDs, and cloud-native tooling, new users often need training or prior experience across all three areas. That combination can slow onboarding and make it harder to get productive quickly.

3. Resource Overhead

Running a full Kubernetes-native PostgreSQL setup (even with automation) generally requires more compute and network resources than a simple managed database, plus careful planning around storage classes, affinities, and node sizing. As a result, it’s not always the most cost-efficient choice for lightweight workloads.

4. Ecosystem Support Can Be Mixed

Although the Cloud native pg operator is solid, some third-party tools or monitoring integrations don’t work as seamlessly out of the box as they do with mainstream managed services (e.g., AWS RDS or Azure Database for PostgreSQL). Certain extensions or edge use cases can also require extra validation or tuning.

5. Vendor & Feature Expectations

EDB adds enterprise features, but those enhancements can come with licensing or support tiers, and the full benefit isn’t always free or open source. Teams evaluating “Postgres AI” features should carefully confirm what’s included versus what sits behind commercial plans. Review collected by and hosted on G2.com.

What I like best about EDB Postgres AI for CloudNativePG is how seamlessly it brings enterprise PostgreSQL capabilities into a truly Kubernetes-native environment. It preserves the declarative, operator-driven model while adding production-grade features like advanced security, high availability, observability, and performance tooling. The integration feels natural rather than layered on, which makes day-two operations smoother. I especially appreciate the balance between open-source flexibility and enterprise support, enabling teams to scale confidently, modernize workloads, and run mission-critical databases in Kubernetes without sacrificing reliability, governance, or developer agility. Review collected by and hosted on G2.com.

One downside of EDB Postgres AI for CloudNativePG is the added complexity that comes with enterprise layering. While the additional features are powerful, they can increase operational overhead compared to running a lightweight, community-only PostgreSQL setup. Licensing and pricing may also be a concern for smaller teams or startups that don’t need advanced enterprise capabilities.

There can also be a learning curve when integrating advanced security, observability, or performance tooling into existing Kubernetes workflows. For teams already comfortable with pure open-source stacks, the shift toward a more platform-driven approach may feel heavier than necessary. Review collected by and hosted on G2.com.

I like EDB Postgres AI for CloudNativePG for its robust automation for high availability and self-healing failovers. The rolling updates and continuous backup features stand out, as they ensure zero-downtime deployments and effortless point-in-time recovery in Kubernetes environments. It truly simplifies scaling PostgreSQL for microservices without the overhead of traditional VM management. Additionally, using it with Kubernetes, Helm, and monitoring tools like Prometheus/Grafana helps automate deployment and monitor PostgreSQL clusters effectively. Review collected by and hosted on G2.com.

I don't like the steep learning curve for Kubernetes novices, which slows down the setup. Major upgrades are complex and manual. The resource use feels high for small workloads. Review collected by and hosted on G2.com.

I like EDB Postgres AI for CloudNativePG because it automates PostgreSQL deployment and management in Kubernetes. It simplifies tasks like scaling, backups, and recovery while maintaining high availability and reliability. The automation reduces manual operational efforts, improving database reliability and minimizing downtime. This allows us to focus more on application and data development instead of routine database management. Its strong automation, scalability, and Kubernetes integration are particularly beneficial for managing PostgreSQL clusters. Review collected by and hosted on G2.com.

The initial setup can be complex, especially for teams new to Kubernetes. Documentation and troubleshooting guidance could be more detailed, and the initial setup and learning curve could be improved. Review collected by and hosted on G2.com.

I like EDB Postgres AI because it feels practical. You get trusted Postgres plus better performance, smarter insights, easier tuning, and fewer surprises in day to day work Review collected by and hosted on G2.com.

The downside of EDB Postgres AI is it can feel complex at first. There is a learning curve, some features feel overkill, and costs and setup can add friction early on Review collected by and hosted on G2.com.

I use EDB Postgres AI for CloudNativePG as my go-to managed PostgreSQL because it seamlessly combines enterprise-grade PostgreSQL compatibility with cloud native environments. The level of automation is impressive, particularly the automated high availability and failovers as well as AI-driven performance, which reduce operational risk and improve the overall system. The initial setup was smoother than expected. Review collected by and hosted on G2.com.

In certain advanced scenarios, there's a lack of document depth. There should be more end-to-end architecture examples and some real-world scenario walkthroughs. Review collected by and hosted on G2.com.

We do not need to setup another VM for each Workload requiring a Relational DB. Setting up a EDB CNP is really easy now. Just by the input of some basic properties the operator spins up a Postgres Cluster on it's own and in combination with the ClusterImageCatalog patching the Clusters is very easy since the operator is conducting a rolling restart of the pods on its own on updating the Catalog. We also like the many options the Operator already provides in configuring the Postgres Cluster.

Cudos also to the Operator which has become much more stable since we started initially ~2 years ago. Review collected by and hosted on G2.com.

We are still missing major upgrades on the Clusters in a user friendly way. I know there is progress on EDB's Development making customers life more easy, but we are still eagerly awating it. The current solution based on replicating data to a new cluster with a higher major version is far to complicated and time consuming for a bunch of Clusters.

Besides we are missing the ClusterImageCatalog formerly provided here https://raw.githubusercontent.com/EnterpriseDB/docker-postgresql/refs/heads/main/image-catalogs/ClusterImageCatalog-ubi9.yaml

It was very handy to pull this Catalog and apply it to the Cluster using Terraform and with that triggering the operator to patch all Clusters. Review collected by and hosted on G2.com.