Converged Analytics
The New Analytics Stack Is Converging. Who Will Own It?
Why Consolidating Your Analytics is Really a Question of Control
The analytics stack is converging, and the payoff is real: less duplicated data, fewer pipelines to maintain, faster time to insight. But convergence comes with a question: who’s in control?
Many paths to a unified stack solve the pipeline problem, but force you to rely on vendor-controlled formats, engines, deployment, and cost, leaving your data strategy at their mercy. This session looks at convergence through the lens of ownership: what it takes to consolidate without giving up control — so you can own the full data lifecycle, from core operational data to long-term historical records to the agents that access them.
Postgres data doesn't have to leave Postgres to become an analytical estate. In this session, we'll show how the Postgres Analytics Accelerator (PGAA) publishes live transactional data into an open Lakehouse built on Apache Iceberg — creating one current, shared source that ClickHouse and WarehousePG both read from natively. You'll see how ClickHouse delivers millisecond-speed analytics for dashboards, fraud scoring, and monitoring, while WarehousePG handles petabyte-scale roll-ups, complex BI, and in-database ML, with GPU-accelerated offload to Spark for the heaviest workloads. A live demo will trace a single transaction from write in Postgres through real-time analysis in ClickHouse to historical depth in WarehousePG — the full data lifecycle, one open ecosystem, zero duplication of effort. We'll close with benchmark results (up to 99x improvement with GPU acceleration) and a practical migration path for teams currently wrangling Greenplum or custom ETL pipelines.
Postgres for the Full Data Lifecycle
Converged Analytics: Copy Once, Query Everywhere
Most attempts to unify analytics still move data to get the job done: faster pipelines, tighter syncs, more automated ETL. That's real progress, but it's still movement — and every copy created has a cost, whether it shows up as stale data, bloated bills, or lost control over where data lives and who can touch it.
In this session, we show a different approach and prove it live on EDB Postgres AI: copy once, query everywhere. Transactional and analytical engines query the same governed data in place, so there's less data moving and fewer pipelines to build and maintain between systems. We'll cover why this shift is happening now, driven by cost, freshness, control, and the need to make AI work on live data, and why moving less data is becoming a bigger lever than moving it faster.
A retail shopper's intent changes by the minute, but the model that knows their taste was trained overnight. Personalization breaks in the gap between the two. This session shows a next-best-action pipeline built on EDB Postgres AI with just one copy of data in Iceberg: ClickHouse ingests live clickstream events as the shopper browses, while WarehousePG runs the nightly segmentation job that produces buying propensity scores and customer profiles. Both engines read the same lakehouse tables, so the offer served at checkout combines what the shopper clicked thirty seconds ago with what the model learned about them last night. We'll walk through the architecture, then demo a sub-second offer decision end to end. A textbook case for converged analytics under real latency pressure.
Real-Time Personalization / Next-Best-Action
Observability and Log Consolidation
Observability costs scale with ingest, which is why per-GB licensing tends to grow faster than the value of the logs themselves. The usual escape route, a self-run open source stack, trades the bill for an operational burden nobody signed up for. This session looks at consolidating logs and metrics onto EDB Postgres AI with ClickHouse instead: what changes about ingest, retention, and query economics, and what you keep in terms of support and governance. The demo covers billions of log and metric records ingested and served with sub-second response, including time-series analysis and the dashboards built on top.
Giving an AI agent query access to your data is straightforward. Being able to prove afterwards what it accessed, why, and on whose authority is the harder problem, and it's the one that decides whether agents make it into production. This session covers the controls that make agent access defensible: purpose-bound access scoped to a specific task, verifiable intent captured at query time, and a full audit trail across every engine the agent touches. We'll demo an agent making a real-time decision against data on EDB Postgres AI spanning Postgres, ClickHouse, and the Iceberg lakehouse, then reconstruct exactly what it did from the audit record.