EDB unifica analítica en Postgres para agentes de IA

¿Qué ha ocurrido?

EnterpriseDB (EDB) presentó capacidades de analítica convergente para su base de datos gestionada Postgres AI, con el objetivo de que los agentes de IA accedan a datos operacionales y analíticos sin necesidad de réplicas ni pipelines ETL. La solución utiliza Apache Iceberg como catálogo compartido, conectando Postgres con motores como ClickHouse, WarehousePG y Spark, mientras los datos operativos permanecen en Postgres y los históricos en almacenamiento de objetos gestionado por Iceberg. Según Max Romanenko, director de ingeniería de EDB, la clave está en que "estamos construyendo desde la capa operativa con Postgres, que es donde las empresas ya ejecutan sus cargas de trabajo más críticas, y expandiéndonos desde allí", en contraste con el enfoque de Databricks que parte del lakehouse. Esta arquitectura elimina la necesidad de mover datos entre sistemas, reduciendo la latencia y los costos de infraestructura.

¿Por qué es importante?

Históricamente, separar bases de datos transaccionales (OLTP) y analíticas (OLAP) era una buena práctica. Sin embargo, los agentes de IA requieren datos frescos y en tiempo real para razonar y actuar. EDB ofrece una alternativa a Databricks LTAP, que parte de un lakehouse y añade capacidades transaccionales. En cambio, EDB parte de Postgres, donde ya residen las cargas críticas empresariales, y expande hacia la analítica sin mover los datos del control del cliente. Esta convergencia responde a la presión de habilitar agentes de IA empresariales que operen sobre datos operacionales frescos, sin esperar pipelines ni réplicas. Como señala InfoWorld, "separar bases de datos transaccionales de sistemas analíticos era, hasta hace poco, considerada una buena arquitectura. Ahora, los proveedores están decidiendo que esa separación se ha convertido en una responsabilidad". EDB apuesta por mantener Postgres como fuente única de verdad operacional, mientras que Databricks centraliza en un lakehouse. La decisión tiene implicaciones directas para empresas reguladas o con requisitos de soberanía de datos, ya que EDB permite que los datos permanezcan en infraestructura controlada por el cliente. Además, promete costos predecibles al evitar duplicaciones. La competencia con Databricks se intensifica, y ambos buscan capturar el creciente mercado de agentes de IA empresariales, que según Gartner podría alcanzar los 50 mil millones de dólares en 2028.

Consecuencias y contexto

Esta decisión arquitectónica tiene implicaciones para empresas reguladas o con requisitos de soberanía de datos, ya que EDB permite que los datos permanezcan en infraestructura controlada por el cliente. Además, promete costos predecibles al evitar duplicaciones. La competencia con Databricks se intensifica, y ambos buscan capturar el creciente mercado de agentes de IA empresariales. Históricamente, la separación OLTP/OLAP surgió por limitaciones técnicas en los años 90, cuando los sistemas transaccionales no podían manejar consultas analíticas pesadas. Sin embargo, con el avance de hardware y software, esta separación se ha vuelto menos necesaria. EDB y Databricks representan dos enfoques opuestos: EDB extiende Postgres (OLTP) hacia la analítica, mientras Databricks extiende el lakehouse (OLAP) hacia lo transaccional. Un antecedente similar fue la convergencia de bases de datos relacionales y NoSQL en la década de 2010, con sistemas como MongoDB que añadieron soporte transaccional. Sin embargo, la convergencia actual está impulsada por la IA, que exige datos frescos para modelos en tiempo real. Para los usuarios, esto significa una reducción de la complejidad operativa: ya no necesitan mantener pipelines ETL separados, lo que reduce la latencia de datos de horas a segundos. Para las empresas, implica un ahorro en costos de infraestructura y mantenimiento, aunque puede generar dependencia del proveedor. En el mercado, se espera que otros proveedores como AWS (con Aurora y Redshift) o Google (con AlloyDB y BigQuery) sigan caminos similares, intensificando la competencia.

Lo que deben saber los lectores

• EDB mantiene Postgres como fuente única de verdad operacional, mientras Databricks centraliza en un lakehouse. Apache Iceberg actúa como capa de catálogo compartido, permitiendo consultas analíticas sin mover datos. La solución está diseñada para empresas que priorizan la soberanía y el control de sus datos. No se requieren pipelines ETL adicionales, lo que reduce latencia y complejidad. Además, EDB ofrece soporte para motores analíticos como ClickHouse (optimizado para consultas en tiempo real), WarehousePG (basado en Postgres) y Spark (para procesamiento distribuido). Los usuarios pueden consultar datos operativos y analíticos desde una única interfaz SQL. Según EDB, la solución ya está disponible en versión preview para clientes de EDB Postgres AI en AWS, Azure y Google Cloud. Los precios se basan en el consumo de recursos informáticos y de almacenamiento, sin costos adicionales por licencias de Iceberg. Para empresas con cargas de trabajo mixtas, esta convergencia promete simplificar la arquitectura de datos y acelerar el tiempo de obtención de insights.