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.
Skip the CDC and ETL step between a transaction and your analysis.
Getting a live transaction in front of an analytical query or a machine learning workload usually means extra steps: a separate CDC tool captures the change, a custom ETL job transforms and loads it, and by the time the data lands in the warehouse, the moment to act on it has often passed.
This session shows how to skip that path: a health insurer's claim, written to EDB Postgres Distributed (PGD), replicates into Apache Iceberg the instant it's written, and WarehousePG reads that same Iceberg data directly—no external CDC tool, no custom code. From there, WarehousePG runs SQL analytics against the full claims history and scores each member, using in-database machine learning, for their likelihood of having a non-preventative claim in the future—while the data is still fresh enough for a care team to act on. It's one instance of a bigger idea: transactional, analytical, and real-time workloads converging on a single, open copy of your data.
From Live Transactions to In-Database Analytics and Machine Learning
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.
From Click to Checkout: Sub-Second Personalization on One Lakehouse
Billions of Logs, Sub-Second Answers: A New Take on Observability
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.