EDB unifies analytics in Postgres for AI agents

What happened?

EnterpriseDB (EDB) introduced convergent analytics capabilities for its managed Postgres AI database, aiming for AI agents to access operational and analytical data without the need for replicas or ETL pipelines. The solution uses Apache Iceberg as a shared catalog, connecting Postgres with engines like ClickHouse, WarehousePG, and Spark, while operational data remains in Postgres and historical data in object storage managed by Iceberg. According to Max Romanenko, director of engineering at EDB, the key is that "we are building from the operational layer with Postgres, which is where companies already run their most critical workloads, and expanding from there," in contrast to Databricks' approach starting from the lakehouse. This architecture eliminates the need to move data between systems, reducing latency and infrastructure costs.

Why is it important?

Historically, separating transactional (OLTP) and analytical (OLAP) databases was a good practice. However, AI agents require fresh, real-time data to reason and act. EDB offers an alternative to Databricks LTAP, which starts from a lakehouse and adds transactional capabilities. Instead, EDB starts from Postgres, where critical enterprise workloads already reside, and expands toward analytics without moving data from customer control. This convergence responds to the pressure to enable enterprise AI agents that operate on fresh operational data, without waiting for pipelines or replicas. As InfoWorld notes, "separating transactional databases from analytical systems was, until recently, considered good architecture. Now, vendors are deciding that separation has become a liability." EDB bets on keeping Postgres as the single source of operational truth, while Databricks centralizes in a lakehouse. The decision has direct implications for regulated companies or those with data sovereignty requirements, as EDB allows data to remain in customer-controlled infrastructure. Additionally, it promises predictable costs by avoiding duplication. Competition with Databricks intensifies, and both seek to capture the growing market for enterprise AI agents, which Gartner estimates could reach $50 billion by 2028.

Consequences and context

This architectural decision has implications for regulated companies or those with data sovereignty requirements, as EDB allows data to remain in customer-controlled infrastructure. Additionally, it promises predictable costs by avoiding duplication. Competition with Databricks intensifies, and both seek to capture the growing market for enterprise AI agents. Historically, the OLTP/OLAP separation arose from technical limitations in the 1990s, when transactional systems could not handle heavy analytical queries. However, with advances in hardware and software, this separation has become less necessary. EDB and Databricks represent two opposing approaches: EDB extends Postgres (OLTP) toward analytics, while Databricks extends the lakehouse (OLAP) toward transactions. A similar precedent was the convergence of relational and NoSQL databases in the 2010s, with systems like MongoDB adding transactional support. However, the current convergence is driven by AI, which demands fresh data for real-time models. For users, this means a reduction in operational complexity: they no longer need to maintain separate ETL pipelines, reducing data latency from hours to seconds. For enterprises, it implies savings in infrastructure and maintenance costs, though it may create vendor lock-in. In the market, other providers like AWS (with Aurora and Redshift) or Google (with AlloyDB and BigQuery) are expected to follow similar paths, intensifying competition.

What readers should know

• EDB keeps Postgres as the single source of operational truth, while Databricks centralizes in a lakehouse. Apache Iceberg acts as a shared catalog layer, enabling analytical queries without moving data. The solution is designed for companies that prioritize data sovereignty and control. No additional ETL pipelines are required, reducing latency and complexity. Additionally, EDB offers support for analytical engines like ClickHouse (optimized for real-time queries), WarehousePG (based on Postgres), and Spark (for distributed processing). Users can query operational and analytical data from a single SQL interface. According to EDB, the solution is already available in preview for EDB Postgres AI customers on AWS, Azure, and Google Cloud. Pricing is based on compute and storage resource consumption, with no additional costs for Iceberg licenses. For companies with mixed workloads, this convergence promises to simplify data architecture and accelerate time to insights.