EDB converges analytics on Postgres to support AI agents EnterpriseDB (EDB) introduced converged analytics capabilities for its managed EDB Postgres AI database service, aiming to support AI agents by unifying transactional and analytical processing on Postgres. The move follows Databricks' similar LTAP offering, but EDB emphasizes keeping operational data on customer-controlled infrastructure rather than moving it to a cloud-managed platform. Separating transactional databases from analytical systems was, until recently, considered good architecture. Now, as enterprises adopt AI agents that continuously read, reason over, and act on business data, data warehouse and database vendors are increasingly deciding that separation has become a liability. Just weeks after Databricks unveiled its Lakehouse Transaction and Analytical Processing LTAP https://www.infoworld.com/article/4185622/databricks-pitches-ltap-as-a-new-foundation-for-agentic-applications.html offering based on Neon Postgres https://www.infoworld.com/article/3985947/databricks-to-acquire-open-source-database-startup-neon-to-build-the-next-wave-of-ai-agents.html to bring operational OLTP https://www.infoworld.com/article/2334535/what-is-oltp-the-backbone-of-ecommerce.html and analytical OLAP https://www.infoworld.com/article/2334471/what-is-olap-analytical-databases.html processing closer together, EnterpriseDB EDB has introduced converged analytics capabilities for its managed EDB Postgres AI https://www.infoworld.com/article/2337015/edb-unveils-edb-postgres-ai.html database service with the same intent. Both vendors are responding to the same pressure of enabling AI agents for enterprises to operate on fresh operational data without waiting for pipelines and replicas, but EDB argues its approach starts from a fundamentally different place. “Databricks is building from the lakehouse https://www.infoworld.com/article/2335877/databricks-open-sources-its-delta-lake-data-lake.html outward, trying to pull transactional capability in through Lakebase,” said Max Romanenko http://linkedin.com/in/maxrom , chief engineering officer at EDB, while “we’re building from the operational layer with Postgres https://www.infoworld.com/article/4062619/the-best-new-features-in-postgres-18.html , which is where enterprises already run their most critical workloads, and expanding from there.” In contrast to Databricks’ lakehouse-centric LTAP, EDB keeps Postgres as the operational source of truth and uses Apache Iceberg as a shared catalog layer connecting Postgres with ClickHouse https://www.infoworld.com/article/4118621/clickhouse-buys-langfuse-as-data-platforms-race-to-own-the-ai-feedback-loop.html , WarehousePG, and Spark https://www.infoworld.com/article/2259224/what-is-apache-spark-the-big-data-platform-that-crushed-hadoop.html compute engines, Romanenko said. In this way, operational data remains in Postgres while historical and tiered data is stored in Iceberg https://www.infoworld.com/article/3479001/why-apache-iceberg-is-on-fire-right-now.html -managed object storage, allowing analytical engines to query the same data through a common catalog without requiring separate copies or ETL https://www.infoworld.com/article/2257688/etl-is-dead.html pipelines, he said. That architectural distinction matters to EDB, according to Romanenko, because the vendor is targeting enterprises that want AI and analytics capabilities without moving sensitive data into a cloud-managed platform: “For us, it’s always been about the data sitting on infrastructure the customer owns and controls.” EDB’s promotion of control “will resonate with CIOs focusing on sovereignty, regulated data, and hybrid deployment,” said Stephanie Walter https://www.linkedin.com/in/slwalter , practice leader of AI stack at HyperFrame Research. “This should enable them to run AI and analytics closer to the data, on infrastructure that their enterprise controls, without creating yet another proprietary data estate.” For Ashish Chaturvedi https://www.hfsresearch.com/team/ashish-chaturvedi , leader of executive research at HFS Research, EDB’s approach in converged analytics will offer more predictable costs than Databricks LTAP for CIOs already struggling to manage their analytics and AI budgets. EDB’s per-core pricing model can make costs easier to forecast than consumption-based cloud data platforms, where query volumes, AI workloads, and data processing demands can cause bills to fluctuate, Chaturvedi said. But predictable bills are not necessarily lower bills, warned, Igor Ikonnikov https://www.infotech.com/profiles/igor-ikonnikov , advisory fellow at Info-Tech Research Group. “The hardware requirements for high-speed operational data processing are higher and relatively more expensive compared to cheap lakehouse storage,” he said. EDB’s architecture could also simplify data governance by reducing the number of platforms enterprises need to manage. Since operational, analytical, and AI workloads can access data through a common Postgres-Iceberg foundation, enterprises may be able to avoid deploying and governing multiple specialized data stores, and so have fewer systems to license and secure, according to Devin Pratt https://my.idc.com/getdoc.jsp?containerId=PRF005946 , research director at IDC. EDB’s converged analytics could also simplify operations for developers and data engineering teams. Its architecture reduces the number of systems developers must integrate and maintain, while eliminating much of the pipeline work traditionally required to move data between transactional and analytical systems, according to Walter. And, said Pratt, “Zero-ETL means far less plumbing to build and break, so engineers spend their time creating value.” EDB and Databricks are not the only ones pursuing converged analytics to support agentic systems and other applications needing immediate access to operational data, historical context, and governance controls. Snowflake https://www.infoworld.com/article/4001149/snowflake-acquires-crunchy-data-for-enterprise-grade-postgresql-to-counter-databricks-neon-buy.html has been expanding support for operational workloads by embracing open table formats,and Microsoft has combined transactional and analytical services under a broader data architecture via its Fabric platform https://www.infoworld.com/article/3991006/why-microsoft-is-unifying-data-and-ai-within-fabric.html . Converged analytics, though, was only one part of EDB’s update to its Postgres AI platform. It has also made generally available what it calls an “agentic database” feature, designed to automate routine database administration tasks. The system continuously monitors hundreds of operational and performance metrics, detects anomalies, recommends corrective actions, and, where enterprise policies permit, can automatically apply fixes, the company said. These automated agents can help enterprises optimize and tune their databases up to 10 times faster, it said. Walter remained skeptical: “It is more an evolution of autonomous database concepts than a wholly new category. Oracle and other database vendors have offered autonomous database capabilities for years.” Where EDB can differentiate itself, she said, is in extending those autonomous capabilities with AI-driven reasoning, automated remediation, and governance controls that allow enterprises to determine how much authority the system receives.