EDB Postgres AI for CloudNativePG Reseñas y Detalles del Producto

Me gusta la función donde podemos construir aplicaciones de Gen AI directamente en EDB Postgres AI para CloudNativePG. La escalabilidad de los modelos de IA dentro de la base de datos es otro aspecto que aprecio. La función de cargas de trabajo unificadas, que permite tanto consultas transaccionales tradicionales como tareas de IA en la misma plataforma, me destaca. Además, me gusta la función de gestor de datos híbrido. Con estas capacidades, es útil para manejar el creciente volumen de datos de chatbots y soporta la búsqueda vectorial, que se utiliza ampliamente para aplicaciones de IA. Reseña recopilada por y alojada en G2.com.

Es muy difícil crear la configuración inicial y la base de datos de configuración para cargas de trabajo de IA debido a la documentación inadecuada, por lo que me gustaría mejorar el contenido del documento. Hay algunas características avanzadas en EDB, pero debido a la falta de documentación, no sabemos cómo usarlas. PostgreSQL utiliza un nodo escritor principal con múltiples réplicas de lectura, lo que se convierte en un cuello de botella para cargas de trabajo de escritura muy altas. Debería seguir un modelo similar al de Google Spanner para que podamos escalar horizontalmente. Es muy difícil configurarlo inicialmente sin un experto en PostgreSQL. El desafío que enfrentamos es cómo configurar las replicaciones y los contenedores, y también es muy difícil configurar la seguridad. Reseña recopilada por y alojada en G2.com.

Utilizo EDB Postgres AI para CloudNativePG para gestionar mis bases de datos PostgreSQL en Kubernetes sin esfuerzo. Automatiza el despliegue de clústeres, el escalado, las copias de seguridad y la conmutación por error, lo que reduce significativamente mi esfuerzo manual. Me gusta lo mucho que simplifica ejecutar PostgreSQL en Kubernetes, y la automatización me ahorra mucho tiempo. Las características de alta disponibilidad son una gran ventaja, proporcionando fiabilidad y confianza en producción. La configuración declarativa se integra sin problemas con los flujos de trabajo de GitOps, haciendo que las operaciones sean más predecibles y consistentes. En general, está bien adaptado para entornos de producción en Kubernetes. Reseña recopilada por y alojada en G2.com.

Una cosa que podría mejorarse con EDB Postgres AI para CloudNativePG es la curva de aprendizaje, ya que puede parecer compleja al principio si eres nuevo en los operadores de Kubernetes. Algunas operaciones avanzadas y actualizaciones de versión también requieren una planificación cuidadosa, lo que puede añadir carga. Simplificar la documentación y facilitar las actualizaciones de versiones principales de PostgreSQL mejoraría aún más la experiencia. Reseña recopilada por y alojada en G2.com.

Me gusta la fuerte integración con Kubernetes y la automatización que proporciona para gestionar clústeres de PostgreSQL. Las características de conmutación por error automatizada y alta disponibilidad nos dan confianza de que nuestras bases de datos permanecen estables incluso durante fallos de nodos. Otro aspecto destacado son las ideas de rendimiento inteligentes. Las recomendaciones impulsadas por IA ayudan a identificar consultas lentas y mejoras de configuración, lo que reduce el tiempo dedicado a la resolución de problemas manual. También aprecio el modelo de configuración declarativa, que se alinea bien con las prácticas de DevOps y los flujos de trabajo de infraestructura como código. Hace que los despliegues sean más consistentes y fáciles de gestionar en diferentes entornos. En general, la combinación de fiabilidad de nivel empresarial con flexibilidad nativa de la nube es lo que más destaca. Reseña recopilada por y alojada en G2.com.

Aunque la experiencia general ha sido positiva, hay algunas áreas que podrían mejorarse. La configuración inicial y la configuración avanzada pueden parecer complejas, especialmente para los equipos que son nuevos en Kubernetes o CloudNativePG. Algunos escenarios requieren un entendimiento más profundo de los internos de PostgreSQL y la arquitectura de clústeres. Además, una documentación más clara para ciertos casos de uso avanzados y parámetros de ajuste sería útil. Aunque la documentación es generalmente buena, más ejemplos prácticos o guías de implementación en el mundo real facilitarían la incorporación. Una mejor visibilidad de los niveles de precios y las diferencias de características también ayudaría a los equipos a planificar mejor antes de adoptarlo a gran escala. Reseña recopilada por y alojada en G2.com.

1) Diseño nativo de Kubernetes con Cloud Native PG.

2) Capacidades de PostgreSQL de nivel empresarial respaldadas por EnterpriseDB.

3) Fuerte alineación entre las iniciativas de IA y la plataforma de datos.

4) Simplicidad operativa que facilita el trabajo diario para los equipos de DevOps. Reseña recopilada por y alojada en G2.com.

1. Complejidad para Equipos Pequeños

Aunque es potente, esta pila puede parecer pesada para equipos de desarrollo pequeños, aplicaciones simples sin SLAs estrictos, o proyectos que no necesitan operaciones de base de datos completamente nativas de Kubernetes. En esos casos, algunos equipos terminan dedicando más tiempo a la configuración y al trabajo de plataforma que a construir características de la aplicación.

2. Curva de Aprendizaje Más Pronunciada

Debido a que combina los internos de PostgreSQL, operadores y CRDs de Kubernetes, y herramientas nativas de la nube, los nuevos usuarios a menudo necesitan capacitación o experiencia previa en las tres áreas. Esa combinación puede ralentizar la incorporación y hacer que sea más difícil ser productivo rápidamente.

3. Sobrecarga de Recursos

Ejecutar una configuración de PostgreSQL completamente nativa de Kubernetes (incluso con automatización) generalmente requiere más recursos de cómputo y red que una base de datos gestionada simple, además de una planificación cuidadosa en torno a las clases de almacenamiento, afinidades y dimensionamiento de nodos. Como resultado, no siempre es la opción más rentable para cargas de trabajo ligeras.

4. Soporte del Ecosistema Puede Ser Mixto

Aunque el operador Cloud native pg es sólido, algunas herramientas de terceros o integraciones de monitoreo no funcionan tan perfectamente desde el principio como lo hacen con servicios gestionados convencionales (por ejemplo, AWS RDS o Azure Database for PostgreSQL). Ciertas extensiones o casos de uso extremos también pueden requerir validación o ajuste adicional.

5. Expectativas de Proveedor y Características

EDB añade características empresariales, pero esas mejoras pueden venir con licencias o niveles de soporte, y el beneficio completo no siempre es gratuito o de código abierto. Los equipos que evalúan características de "Postgres AI" deben confirmar cuidadosamente qué está incluido frente a lo que está detrás de planes comerciales. Reseña recopilada por y alojada en G2.com.

Lo que más me gusta de EDB Postgres AI para CloudNativePG es cómo integra sin problemas las capacidades de PostgreSQL empresarial en un entorno verdaderamente nativo de Kubernetes. Preserva el modelo declarativo, impulsado por operadores, mientras añade características de nivel de producción como seguridad avanzada, alta disponibilidad, observabilidad y herramientas de rendimiento. La integración se siente natural en lugar de superpuesta, lo que hace que las operaciones del segundo día sean más fluidas. Aprecio especialmente el equilibrio entre la flexibilidad de código abierto y el soporte empresarial, lo que permite a los equipos escalar con confianza, modernizar cargas de trabajo y ejecutar bases de datos críticas en Kubernetes sin sacrificar la fiabilidad, la gobernanza o la agilidad del desarrollador. Reseña recopilada por y alojada en G2.com.

Una desventaja de EDB Postgres AI para CloudNativePG es la complejidad añadida que viene con la capa empresarial. Aunque las características adicionales son poderosas, pueden aumentar la carga operativa en comparación con ejecutar una configuración de PostgreSQL ligera y solo comunitaria. La concesión de licencias y los precios también pueden ser una preocupación para equipos más pequeños o startups que no necesitan capacidades empresariales avanzadas.

También puede haber una curva de aprendizaje al integrar herramientas avanzadas de seguridad, observabilidad o rendimiento en los flujos de trabajo existentes de Kubernetes. Para los equipos que ya están cómodos con pilas puramente de código abierto, el cambio hacia un enfoque más orientado a la plataforma puede parecer más pesado de lo necesario. Reseña recopilada por y alojada en G2.com.

Me gusta EDB Postgres AI para CloudNativePG por su robusta automatización para alta disponibilidad y conmutaciones por error de auto-recuperación. Las actualizaciones continuas y las características de respaldo continuo destacan, ya que aseguran implementaciones sin tiempo de inactividad y una recuperación puntual sin esfuerzo en entornos de Kubernetes. Realmente simplifica la escalabilidad de PostgreSQL para microservicios sin la sobrecarga de la gestión tradicional de máquinas virtuales. Además, usarlo con Kubernetes, Helm y herramientas de monitoreo como Prometheus/Grafana ayuda a automatizar la implementación y monitorear los clústeres de PostgreSQL de manera efectiva. Reseña recopilada por y alojada en G2.com.

No me gusta la pronunciada curva de aprendizaje para los principiantes de Kubernetes, lo que ralentiza la configuración. Las actualizaciones importantes son complejas y manuales. El uso de recursos parece alto para cargas de trabajo pequeñas. Reseña recopilada por y alojada en G2.com.

Me gusta EDB Postgres AI para CloudNativePG porque automatiza el despliegue y la gestión de PostgreSQL en Kubernetes. Simplifica tareas como el escalado, las copias de seguridad y la recuperación, manteniendo al mismo tiempo una alta disponibilidad y fiabilidad. La automatización reduce los esfuerzos operativos manuales, mejorando la fiabilidad de la base de datos y minimizando el tiempo de inactividad. Esto nos permite centrarnos más en el desarrollo de aplicaciones y datos en lugar de en la gestión rutinaria de bases de datos. Su fuerte automatización, escalabilidad e integración con Kubernetes son particularmente beneficiosas para gestionar clústeres de PostgreSQL. Reseña recopilada por y alojada en G2.com.

La configuración inicial puede ser compleja, especialmente para equipos nuevos en Kubernetes. La documentación y la guía de resolución de problemas podrían ser más detalladas, y la configuración inicial y la curva de aprendizaje podrían mejorarse. Reseña recopilada por y alojada en G2.com.

Me gusta EDB Postgres AI porque se siente práctico. Obtienes Postgres confiable más mejor rendimiento, ideas más inteligentes, ajuste más fácil y menos sorpresas en el trabajo diario. Reseña recopilada por y alojada en G2.com.

La desventaja de EDB Postgres AI es que puede parecer complejo al principio. Hay una curva de aprendizaje, algunas funciones parecen excesivas, y los costos y la configuración pueden añadir fricción al principio. Reseña recopilada por y alojada en G2.com.

Utilizo EDB Postgres AI para CloudNativePG como mi opción preferida de PostgreSQL gestionado porque combina sin problemas la compatibilidad de PostgreSQL de nivel empresarial con entornos nativos de la nube. El nivel de automatización es impresionante, particularmente la alta disponibilidad automatizada y los conmutadores por error, así como el rendimiento impulsado por IA, que reducen el riesgo operativo y mejoran el sistema en general. La configuración inicial fue más sencilla de lo esperado. Reseña recopilada por y alojada en G2.com.

En ciertos escenarios avanzados, hay una falta de profundidad en los documentos. Debería haber más ejemplos de arquitectura de extremo a extremo y algunos recorridos por escenarios del mundo real. Reseña recopilada por y alojada en G2.com.

No necesitamos configurar otra máquina virtual para cada carga de trabajo que requiera una base de datos relacional. Configurar un EDB CNP es realmente fácil ahora. Solo con la entrada de algunas propiedades básicas, el operador inicia un clúster de Postgres por sí solo y, en combinación con el parche del ClusterImageCatalog, parchear los clústeres es muy fácil ya que el operador realiza un reinicio gradual de los pods por sí solo al actualizar el catálogo. También nos gustan las muchas opciones que el operador ya ofrece para configurar el clúster de Postgres.

Felicitaciones también al operador, que se ha vuelto mucho más estable desde que comenzamos inicialmente hace aproximadamente 2 años. Reseña recopilada por y alojada en G2.com.

Todavía nos faltan actualizaciones importantes en los Clusters de una manera amigable para el usuario. Sé que hay avances en el desarrollo de EDB que facilitan la vida de los clientes, pero todavía lo estamos esperando con ansias. La solución actual basada en replicar datos a un nuevo cluster con una versión principal más alta es demasiado complicada y lleva mucho tiempo para un montón de Clusters. Además, nos falta el ClusterImageCatalog que antes se proporcionaba aquí https://raw.githubusercontent.com/EnterpriseDB/docker-postgresql/refs/heads/main/image-catalogs/ClusterImageCatalog-ubi9.yaml Era muy útil obtener este catálogo y aplicarlo al Cluster usando Terraform y con eso activar el operador para parchear todos los Clusters. Reseña recopilada por y alojada en G2.com.