Avis et détails du produit EDB Postgres AI for CloudNativePG

J'aime la fonctionnalité où nous pouvons construire une application Gen AI directement sur EDB Postgres AI pour CloudNativePG. L'évolutivité des modèles d'IA au sein de la base de données est un autre aspect que j'apprécie. La fonctionnalité de charges de travail unifiées, permettant à la fois des requêtes transactionnelles traditionnelles et des tâches d'IA sur la même plateforme, se distingue pour moi. De plus, j'aime la fonctionnalité de gestionnaire de données hybride. Avec ces capacités, c'est utile pour gérer les données croissantes des chatbots et prend en charge la recherche vectorielle, qui est largement utilisée pour les applications d'IA. Avis collecté par et hébergé sur G2.com.

Il est très difficile de créer la configuration initiale et la base de données de configuration pour les charges de travail d'IA en raison d'une documentation inadéquate, donc j'aimerais améliorer le contenu du document. Il y a certaines fonctionnalités avancées dans EDB, mais en raison du manque de documentation, nous ne savons pas comment les utiliser. PostgreSQL utilise un nœud principal d'écriture avec plusieurs répliques de lecture, ce qui devient un goulot d'étranglement pour des charges de travail d'écriture très élevées. Il devrait suivre un modèle similaire à Google Spanner afin que nous puissions évoluer horizontalement. Il est très difficile de configurer initialement sans expert en PostgreSQL. Le défi auquel nous avons été confrontés est de savoir comment configurer les réplications et les conteneurs, et il est également très difficile de configurer la sécurité. Avis collecté par et hébergé sur G2.com.

J'utilise EDB Postgres AI pour CloudNativePG afin de gérer mes bases de données PostgreSQL sur Kubernetes sans effort. Il automatise le déploiement des clusters, la mise à l'échelle, les sauvegardes et le basculement, ce qui réduit considérablement mon effort manuel. J'aime la façon dont il simplifie l'exécution de PostgreSQL dans Kubernetes, et l'automatisation me fait gagner beaucoup de temps. Les fonctionnalités de haute disponibilité sont un grand atout, offrant fiabilité et confiance en production. La configuration déclarative s'intègre parfaitement aux workflows GitOps, rendant les opérations plus prévisibles et cohérentes. Dans l'ensemble, il est bien adapté aux environnements Kubernetes de production. Avis collecté par et hébergé sur G2.com.

Une chose qui pourrait être améliorée avec EDB Postgres AI pour CloudNativePG est la courbe d'apprentissage — elle peut sembler complexe au début si vous êtes nouveau dans les opérateurs Kubernetes. Certaines opérations avancées et les mises à niveau de version nécessitent également une planification minutieuse, ce qui peut ajouter une surcharge. Simplifier la documentation et faciliter les mises à niveau majeures de la version PostgreSQL rendraient l'expérience encore meilleure. Avis collecté par et hébergé sur G2.com.

J'aime l'intégration forte avec Kubernetes et l'automatisation qu'elle offre pour gérer les clusters PostgreSQL. Les fonctionnalités de basculement automatique et de haute disponibilité nous donnent confiance que nos bases de données restent stables même en cas de défaillance de nœud. Un autre aspect remarquable est les informations intelligentes sur les performances. Les recommandations pilotées par l'IA aident à identifier les requêtes lentes et les améliorations de configuration, ce qui réduit le temps passé sur le dépannage manuel. J'apprécie également le modèle de configuration déclaratif, qui s'aligne bien avec les pratiques DevOps et les flux de travail d'infrastructure en tant que code. Cela rend les déploiements plus cohérents et plus faciles à gérer à travers les environnements. Dans l'ensemble, la combinaison de la fiabilité de niveau entreprise avec la flexibilité native du cloud est ce qui ressort le plus. Avis collecté par et hébergé sur G2.com.

Bien que l'expérience globale ait été positive, il y a quelques domaines qui pourraient être améliorés. La configuration initiale et la configuration avancée peuvent sembler complexes, surtout pour les équipes qui sont nouvelles à Kubernetes ou CloudNativePG. Certains scénarios nécessitent une compréhension plus approfondie des internes de PostgreSQL et de l'architecture des clusters. De plus, une documentation plus claire pour certains cas d'utilisation avancés et les paramètres de réglage serait utile. Bien que la documentation soit généralement bonne, des exemples plus pratiques ou des guides de déploiement en conditions réelles faciliteraient l'intégration. Une meilleure visibilité sur les niveaux de tarification et les différences de fonctionnalités aiderait également les équipes à mieux planifier avant de l'adopter à grande échelle. Avis collecté par et hébergé sur G2.com.

1) Conception native Kubernetes avec Cloud Native PG.

2) Capacités PostgreSQL de niveau entreprise soutenues par EnterpriseDB.

3) Forte alignement entre les initiatives d'IA et la plateforme de données.

4) Simplicité opérationnelle qui facilite le travail quotidien des équipes DevOps. Avis collecté par et hébergé sur G2.com.

1. Complexité pour les petites équipes

Bien que puissant, cet ensemble technologique peut sembler lourd pour les petites équipes de développement, les applications simples sans SLA stricts, ou les projets qui n'ont pas besoin d'opérations de base de données entièrement natives Kubernetes. Dans ces cas, certaines équipes finissent par passer plus de temps sur la configuration et le travail de plateforme que sur la création de fonctionnalités d'application.

2. Courbe d'apprentissage plus raide

Parce qu'il mélange les internes de PostgreSQL, les opérateurs et CRD Kubernetes, et les outils cloud-native, les nouveaux utilisateurs ont souvent besoin de formation ou d'expérience préalable dans ces trois domaines. Cette combinaison peut ralentir l'intégration et rendre plus difficile d'être productif rapidement.

3. Surcharge de ressources

Exécuter une configuration PostgreSQL entièrement native Kubernetes (même avec automatisation) nécessite généralement plus de ressources de calcul et de réseau qu'une base de données gérée simple, plus une planification minutieuse autour des classes de stockage, des affinités et de la taille des nœuds. En conséquence, ce n'est pas toujours le choix le plus rentable pour les charges de travail légères.

4. Le support de l'écosystème peut être mitigé

Bien que l'opérateur Cloud native pg soit solide, certains outils tiers ou intégrations de surveillance ne fonctionnent pas aussi parfaitement dès le départ qu'avec les services gérés grand public (par exemple, AWS RDS ou Azure Database for PostgreSQL). Certaines extensions ou cas d'utilisation de pointe peuvent également nécessiter une validation ou un ajustement supplémentaires.

5. Attentes des fournisseurs et des fonctionnalités

EDB ajoute des fonctionnalités d'entreprise, mais ces améliorations peuvent être accompagnées de licences ou de niveaux de support, et le plein bénéfice n'est pas toujours gratuit ou open source. Les équipes évaluant les fonctionnalités "Postgres AI" devraient soigneusement confirmer ce qui est inclus par rapport à ce qui se trouve derrière des plans commerciaux. Avis collecté par et hébergé sur G2.com.

Ce que j'aime le plus dans EDB Postgres AI pour CloudNativePG, c'est la façon dont il intègre de manière transparente les capacités PostgreSQL d'entreprise dans un environnement véritablement natif Kubernetes. Il préserve le modèle déclaratif, piloté par opérateur, tout en ajoutant des fonctionnalités de niveau production telles que la sécurité avancée, la haute disponibilité, l'observabilité et les outils de performance. L'intégration semble naturelle plutôt que superposée, ce qui rend les opérations du deuxième jour plus fluides. J'apprécie particulièrement l'équilibre entre la flexibilité open-source et le support d'entreprise, permettant aux équipes de se développer en toute confiance, de moderniser les charges de travail et d'exécuter des bases de données critiques dans Kubernetes sans sacrifier la fiabilité, la gouvernance ou l'agilité des développeurs. Avis collecté par et hébergé sur G2.com.

Un inconvénient de l'EDB Postgres AI pour CloudNativePG est la complexité supplémentaire qui accompagne la superposition d'entreprise. Bien que les fonctionnalités supplémentaires soient puissantes, elles peuvent augmenter la charge opérationnelle par rapport à l'exécution d'une configuration PostgreSQL légère et uniquement communautaire. La licence et le prix peuvent également être une préoccupation pour les petites équipes ou les startups qui n'ont pas besoin de capacités avancées d'entreprise.

Il peut également y avoir une courbe d'apprentissage lors de l'intégration d'outils avancés de sécurité, d'observabilité ou de performance dans les flux de travail Kubernetes existants. Pour les équipes déjà à l'aise avec des piles purement open-source, le passage à une approche plus axée sur la plateforme peut sembler plus lourd que nécessaire. Avis collecté par et hébergé sur G2.com.

J'aime EDB Postgres AI pour CloudNativePG pour son automatisation robuste en matière de haute disponibilité et de basculements auto-réparateurs. Les mises à jour continues et les fonctionnalités de sauvegarde continue se démarquent, car elles garantissent des déploiements sans interruption et une récupération ponctuelle sans effort dans les environnements Kubernetes. Cela simplifie vraiment la mise à l'échelle de PostgreSQL pour les microservices sans la surcharge de la gestion traditionnelle des machines virtuelles. De plus, l'utilisation avec Kubernetes, Helm et des outils de surveillance comme Prometheus/Grafana aide à automatiser le déploiement et à surveiller efficacement les clusters PostgreSQL. Avis collecté par et hébergé sur G2.com.

Je n'aime pas la courbe d'apprentissage abrupte pour les novices en Kubernetes, ce qui ralentit la configuration. Les mises à niveau majeures sont complexes et manuelles. L'utilisation des ressources semble élevée pour les petites charges de travail. Avis collecté par et hébergé sur G2.com.

J'aime EDB Postgres AI pour CloudNativePG car il automatise le déploiement et la gestion de PostgreSQL dans Kubernetes. Il simplifie des tâches comme la mise à l'échelle, les sauvegardes et la récupération tout en maintenant une haute disponibilité et fiabilité. L'automatisation réduit les efforts opérationnels manuels, améliorant la fiabilité de la base de données et minimisant les temps d'arrêt. Cela nous permet de nous concentrer davantage sur le développement d'applications et de données au lieu de la gestion de base de données de routine. Sa forte automatisation, sa scalabilité et son intégration avec Kubernetes sont particulièrement bénéfiques pour la gestion des clusters PostgreSQL. Avis collecté par et hébergé sur G2.com.

La configuration initiale peut être complexe, surtout pour les équipes novices en Kubernetes. La documentation et les conseils de dépannage pourraient être plus détaillés, et la configuration initiale ainsi que la courbe d'apprentissage pourraient être améliorées. Avis collecté par et hébergé sur G2.com.

J'aime EDB Postgres AI parce qu'il semble pratique. Vous obtenez un Postgres de confiance avec de meilleures performances, des insights plus intelligents, un réglage plus facile et moins de surprises dans le travail quotidien. Avis collecté par et hébergé sur G2.com.

L'inconvénient de EDB Postgres AI est qu'il peut sembler complexe au début. Il y a une courbe d'apprentissage, certaines fonctionnalités semblent excessives, et les coûts et la configuration peuvent ajouter des frictions dès le départ. Avis collecté par et hébergé sur G2.com.

J'utilise EDB Postgres AI pour CloudNativePG comme ma solution PostgreSQL gérée de prédilection car elle combine parfaitement la compatibilité PostgreSQL de niveau entreprise avec les environnements cloud natifs. Le niveau d'automatisation est impressionnant, en particulier la haute disponibilité et les basculements automatisés ainsi que la performance pilotée par l'IA, qui réduisent le risque opérationnel et améliorent le système global. La configuration initiale a été plus fluide que prévu. Avis collecté par et hébergé sur G2.com.

Dans certains scénarios avancés, il y a un manque de profondeur dans les documents. Il devrait y avoir plus d'exemples d'architecture de bout en bout et quelques présentations de scénarios réels. Avis collecté par et hébergé sur G2.com.

Nous n'avons pas besoin de configurer une autre VM pour chaque charge de travail nécessitant une base de données relationnelle. Configurer un EDB CNP est vraiment facile maintenant. En entrant simplement quelques propriétés de base, l'opérateur lance un cluster Postgres de manière autonome et, en combinaison avec le ClusterImageCatalog, le patching des clusters est très facile puisque l'opérateur effectue un redémarrage progressif des pods de manière autonome lors de la mise à jour du catalogue. Nous apprécions également les nombreuses options que l'opérateur offre déjà pour configurer le cluster Postgres. Félicitations également à l'opérateur qui est devenu beaucoup plus stable depuis que nous avons commencé il y a environ 2 ans. Avis collecté par et hébergé sur G2.com.

Nous manquons encore de mises à niveau majeures sur les Clusters de manière conviviale. Je sais qu'il y a des progrès dans le développement d'EDB pour faciliter la vie des clients, mais nous l'attendons toujours avec impatience. La solution actuelle basée sur la réplication des données vers un nouveau cluster avec une version majeure plus élevée est bien trop compliquée et chronophage pour un grand nombre de Clusters.

De plus, nous manquons le ClusterImageCatalog qui était auparavant fourni ici https://raw.githubusercontent.com/EnterpriseDB/docker-postgresql/refs/heads/main/image-catalogs/ClusterImageCatalog-ubi9.yaml

Il était très pratique de récupérer ce catalogue et de l'appliquer au Cluster en utilisant Terraform, ce qui permettait de déclencher l'opérateur pour mettre à jour tous les Clusters. Avis collecté par et hébergé sur G2.com.