Two days of real-time insight

As AI agents become a new consumer of enterprise data, data infrastructure needs to evolve with them. Real-time analytics has focused on helping people understand what is happening faster. In the Agentic Era, the challenge goes further: enabling AI to continuously access fresh data, understand multimodal context, and reason in the latest state of business. In this opening keynote, we’ll explore how Apache Doris 5.0 is moving from real-time analytics toward real-time intelligence—from multimodal lakehouses and incremental computing to AI-native data interaction, agent observability, and production-ready infrastructure. The question is no longer just how fast we can analyze data, but how fast data can become intelligent.

AI is reshaping the lakehouse beyond traditional rows and tables. As applications increasingly work with structured data, text, embeddings, images, and other multimodal content, the data infrastructure underneath them must evolve as well. In this session, we’ll explore how Apache Doris 5.0 is extending the lakehouse toward multimodal analytics and retrieval. We’ll look at a real-world Doris + Paimon use case from Kuaishou, and then go deeper into AI-native data infrastructure with Lance—showing how open data formats, vector retrieval, and analytical engines can work together across AI and analytics workloads. Together, these perspectives point toward a more open Multimodal Lakehouse: one where the same data can power search, analytics, retrieval, and AI.

Agentic Analytics is reshaping how enterprises interact with data, built on three foundational pillars: the Analytics Agent, the Context Layer, and the Analytical Database. First, the Analytics Agent: Web-Native and Enterprise-Ready. Web-based Analytics Agents are better suited for enterprise adoption than desktop agents, offering native support for multi-user collaboration, centralized governance, fine-grained access control, and auditing. Second, the Context Layer: Open, Markdown-Based Knowledge. A Markdown-based filesystem approach provides a unified knowledge foundation, where schemas, semantic metrics, business rules, and documentation are organized as human-readable, Git-versionable, and LLM-friendly files, accessible to agents through MCP servers and APIs. Third, the Analytical Database: Serverless and Elastic. The bursty, highly concurrent, and unpredictable query workloads generated by AI agents call for serverless analytical databases like Apache Doris, with elastic scaling, rapid scale-out, and pay-as-you-go economics. Together, these three pillars establish a complete Agentic Analytics architecture, connecting natural-language interactions with business context and scalable analytical execution to deliver trusted, actionable insights.

AI is changing not only how databases are used, but also how applications and agents connect to them. As workloads evolve from dashboards and traditional applications to agent-driven analytics, hybrid search, multimodal data, and AI runtimes, the connectivity layer is becoming a critical part of architecture. In this joint keynote, Apache Doris and Columnar will explore how database connectivity needs to evolve for the AI era — from Doris’s support for open, high-performance access through Arrow and ADBC, to the broader vision of an Agentic Data Plane, where MCP and tools provide the control plane, while Arrow and ADBC power the movement of data. Together, we’ll discuss what an open connectivity ecosystem could look like for the next generation of AI-native data systems.

AI agents need more than fresh source data—they need business metrics and analytical results that keep pace with change. Yet maintaining those results through repeated batch refreshes introduces delays and costly recomputation. This keynote explores a central question: How do we keep intelligence continuously fresh? Starting with real-world business scenarios, we introduce the incremental computing architecture in Apache Doris 5.0: Row Binlog and Table Stream as the foundation for capturing and consuming changes, with Flink-based pipelines for downstream processing and incremental view maintenance (IVM) for automatically maintaining analytical results within Doris. Practical demos show how inserts, updates, and deletes translate into correctly updated business results, while end-to-end latency measurements reveal how quickly changes reach downstream systems and derived metrics. We conclude with a user case study, connecting the architecture to measurable improvements in data freshness and computational efficiency—and showing what it takes to keep the data behind intelligent applications continuously up to date.

Your agent runs, nothing throws an exception, but the answer is still wrong. These failures are invisible to every monitoring tool you already own. This talk introduces Litefuse, an agent observability and evaluation platform built on Langfuse and Apache Doris, and the shift it enables: from test-driven development to evaluation-driven development — observe, evaluate, improve. Then we go a layer deeper, because agent observability is really a real-time analytics problem. Inverted indexes, clustered trace storage, columnar JSON via VARIANT, and storage-compute separation deliver 10x faster full-text search over traces and up to 88% lower storage cost.

Compute-storage decoupling makes Apache Doris an attractive architecture for building scalable analytical platforms on cloud infrastructure. But running Doris in decoupled mode on Kubernetes introduces a different set of considerations around infrastructure design, ingestion, performance, observability, and disaster recovery. In this session, I will share practical lessons from deploying and operating Apache Doris Decoupled Mode on Azure Kubernetes Service (AKS). The session will cover infrastructure and workload isolation, node-level OS optimizations, high-volume data ingestion using Broker Load, historical data migration using Doris Catalogs, and data modelling and bucketing strategies for write performance. I will also discuss disaster recovery and backups, including the protection and recovery of metadata stored across FoundationDB and Doris FE, along with single-region and multi-region recovery strategies. The goal is to provide a practical, production-oriented view of the decisions and lessons involved in taking Doris Decoupled Mode from an architecture diagram to a reliable cloud-native analytical platform.

Real-time Pricing Engine — we migrated a legacy system of 20+ SQL Server stored procedures (with linked servers and custom change tracking) through a failed 160K-line Spark attempt, to a clean solution: 31 Kafka CDC sink connectors + cascading. Materialized views that compute final prices for 10K SKUs × 100+ stores in ~5 minutes. 200 lines of SQL replaced 160,000 lines of Scala. Streaming CDC Sink — 33 Kafka Connect sink connectors streaming real-time operational data from PostgreSQL, SQL Server, and MongoDB into Doris with exactly-once delivery and automatic schema evolution. Query Analytics Platform — Doris reads our Iceberg lakehouse via external catalog, rebuilds pre-computed aggregations, and powers executive dashboards showing query costs, cluster utilization, and platform health. High-Concurrency Point Queries — we used Doris as a cache layer with row store and PreparedStatement short-circuit optimization. It worked — but I'll honestly share why I eventually moved this to PostgreSQL, and what I learned. Metadata Catalog with Search — we're building a DataHub replacement entirely on Doris: NGram BloomFilter indexes for substring search, inverted indexes for keyword search, and IVF vector indexes for multilingual semantic search. No Elasticsearch, no Neo4j — just Doris.

HubSpot's CRM data is highly varied: customers define their own objects and properties, while search and analytical queries must stay responsive as updates arrive. In this session, Staff Software Engineer Alvaro Tuso explains how HubSpot uses Apache Doris to handle that complexity. He will walk through VARIANT schema design, inverted indexes, merge-on-write ingestion, and a cell-based deployment, then show how the team scaled analytical queries across regions. The talk also covers the difficult parts, including multi-object joins, cache behavior, and security, plus the engineering work done with VeloDB. Expect concrete architecture choices and lessons for building low-latency analytics on evolving CRM data.

Append-only storage simplifies high-throughput log ingestion, but business judgments about those logs can change after the data becomes immutable. Logiqum tested this tension on a live Apache Doris deployment ingesting real router, macOS, Windows and OTLP traffic, using a 73-million-row store to compare alternative designs for noise filtering and changing classifications. This session presents the measured write, query, storage and operational trade-offs of each approach, then explains how the team separated immutable facts from mutable decisions. Attendees will learn when append-only modeling is a practical advantage, when it shifts complexity downstream, and how to evaluate the trade-off with evidence.

How GreenSM — Vietnam's leading EV ride-hailing platform — built a live, personalized destination recommendation engine on a single unified analytics + serving database.

How we challenged past architectural and database decisions, leveraging Apache Doris to meet our design goals for high speed ingest at the network edge.

Kafka powers many real-time analytics pipelines, but operating it at scale often involves high storage costs, slow scaling, and complex cluster management. This session introduces AutoMQ, a cloud-native streaming platform that reimplements Kafka’s storage layer on object storage while preserving compatibility with existing Kafka applications and tools. We’ll explain how AutoMQ makes Kafka more cost-effective, elastic, and easier to operate.

Apache Fluss is rethinking how streaming data is stored, managed, and accessed in the modern lakehouse. Designed as a real-time streaming storage layer, Fluss brings together low-latency streaming, log and primary-key tables, and seamless integration with open lakehouse formats. In this session, we will explore the design philosophy behind Apache Fluss, its core architecture, and the real-world scenarios it aims to address. We will then look at how Fluss works with OLAP engines like Apache Doris to bridge streaming data and analytical workloads. Through the recent Apache Doris 5.0 integration, we will demonstrate how fresh data in Fluss and historical data in Apache Paimon can be queried together using SQL, enabling real-time analytics without complex data replication pipelines. Together, Apache Fluss and Apache Doris showcase how open-source communities can collaborate to build the next generation of Streaming Lakehouse architectures.

Kafka, stream-processing engines, and Apache Doris each maintain their own progress and transaction state. This talk follows one Kafka event from a partition, through ingestion, to a visible Doris row - and explains the coordination that makes this path reliable. We trace three designs: Kafka -> Doris, Kafka -> Flink -> Doris, and Kafka -> Spark -> Doris. In Routine Load, Doris reads Kafka records and saves its place in the topic together with the data it loads. In Flink, the engine saves its Kafka progress, asks Doris to prepare the data for commit, and finalizes the Doris write only when the checkpoint succeeds. In Spark, each micro-batch prepares its Doris writes, then the driver finalizes them for that batch. Finally, Doris makes the committed data available for queries. After following the normal flow, we examine what happens if a worker, the processing engine, or Doris fails along the way. In every path, the system must remember both where to resume reading from Kafka and which Doris write belongs to that progress. On restart, it must safely finish the same write or replay the data without creating duplicates. We also clarify the difference between data that is prepared, committed, and finally visible to queries. Attendees will learn how Kafka offsets/Share group, checkpoints or epochs, Doris Stream Load 2PC, transaction labels, FE metadata, and publish-to-visible work together - so they can choose the right ingestion path, validate no-data-loss behavior, and debug duplicates or recovery failures. The talk will also explore how Kafka Share Groups are expected to evolve to support higher-throughput consumption in the future.

Telecom operators generate massive volumes of data from CDRs, mobile money transactions, network events, customer interactions, and operational systems. Traditional data warehouse architectures can struggle to deliver the scalability, flexibility, and real-time performance required for modern analytics. This session shares the practical journey of transforming a traditional Oracle-based telecom reporting environment into a modern Apache Doris-powered real-time lakehouse. It explores how Apache Doris is integrated with technologies such as Kafka, Flink, Hadoop, and BSS/OSS databases to build a scalable platform capable of supporting real-time ingestion, operational analytics, BI, and advanced analytics workloads. The session will walk through the end-to-end architecture—from data ingestion and streaming pipelines through Doris data modeling, optimization, reconciliation, and consumption by BI platforms. It will also highlight real production challenges. Attendees will gain practical insights into migrating from a traditional data warehouse to Apache Doris, designing a real-time telecom lakehouse, optimizing Doris for high-volume analytical workloads, and building a platform that can evolve from traditional BI toward AI and machine-learning use cases.

- Apache OSSIE: An Open Standard for Semantic Layers - DOSI: Translating OSSIE Metrics into Doris SQL - High-Performance API: Powered by Doris Arrow Flight - Doris + DOSI: Integrating Doris Materialized Views with the DOSI Semantic Layer - Datus + DOSI + Doris: Enabling Semantics-Driven Data Agents - Open Semantic Layer for the Agentic Data Stack

Measuring the true impact of fragmented digital touchpoints requires bridging the gap between disconnected systems and final business outcomes. We present a unified multi-tenant platform built on Apache Doris that consolidates diverse external and operational data streams into a single analytical engine. The architecture seamlessly unifies complex entity records across fragmented channels and traces downstream outcomes back to their origins without relying on external data pipelines. Building on this robust analytics foundation, the platform integrates AI-derived signals—such as interaction sentiment, event quality, and AI-assistant visibility scores—directly into the warehouse. It further extends traditional reporting by utilizing stored vectors and language model outputs to evaluate search performance, surface content gaps, and orchestrate automated decision workflows. We share practical design decisions for operating this end-to-end pipeline in production, highlighting how unifying data operations and machine learning insights within one system reshapes customer-facing dashboards.

This session shares a real-world transition from a centrally managed ClickHouse warehouse where data ultimately dead-ended with a team that was responsible for maintaining it, but was not the team actually using or depending on it. The result was a familiar pattern: operational teams either built their own data stores or relied on a corporate store through an intermediary team that sat between the data and the people who cared about it most. We inverted that model with Apache Doris. Instead of one central team owning everything, we built a trusted Doris data foundation with high-quality, clean base tables, then helped other teams bring their data into the shared platform. From there, each team could build its own views and materialized views around the use cases it actually cared about — from BI and fraud prevention to content moderation, recommendations, and AI. The interesting part was not simply moving from ClickHouse to Apache Doris, but changing who owns the data, who is responsible for its quality, and who gets to turn it into useful data products. The experience also raised practical questions around trust, ownership, governance, and how much centralization is actually helpful when the people closest to the data are the ones who need to make decisions with it.

AI assistants write fluent SQL, but they don't know your Apache Doris lakehouse. They can't tell which catalog holds the customers, which key joins the tables, or which Iceberg partition keeps a query from scanning everything. This session follows one business question through a Doris cluster that spans internal tables, Iceberg and a MySQL JDBC catalog. An engineer answers it first in DBeaver, then an AI agent tries the same task. The agent's first answer looks plausible but is wrong. We'll show what the agent needs to be taught: structure, meaning through table and column comments, and business rules captured in views. We'll also cover what it should never see and how DBeaver Community and Enterprise control what leaves your machine. Finally, we'll set guardrails in Doris itself: read-only users, workload groups and query timeouts. You'll leave with a practical checklist for letting humans and agents safely share the same data.

Large fleets of connected devices produce a continuous stream of small updates. At production scale, the challenge is to maintain many simultaneous connections, handle high message rates, and make the incoming data available for timely analysis. This session explains why MQTT fits device communication and how EMQX and Apache Doris work together for real-time IoT analytics. We will follow the native integration from MQTT messages through EMQX rules and batched SQL writes into Doris, then show how SQL can answer a fleet-wide question using recent telemetry. Along the way, we will discuss horizontal scaling and the trade-off between batching efficiency and data freshness. Attendees will leave with a clear understanding of the integration path and how to evaluate it against their own workloads.

In this session, we’re going to discuss the story of iceberg-rust, the official Rust implementation of Apache Iceberg. It began when Xuanwo started a project named Icelake. At that time, he was a database engineer at Databend, and he wanted to build a Rust-based open lake implementation, especially for Apache Iceberg. He was then joined by the RisingWave team, along with other open-source community members, and Icelake grew quickly. At the same time, the Apache Iceberg community was also looking for a Rust implementation of Iceberg, so they collaborated with the Icelake community and officially started iceberg-rust as part of the Apache Iceberg project. Icelake was then sunset, and users migrated to iceberg-rust, which is now a thriving project with around 199 contributors, 1.4K GitHub stars, and 11 releases, and is used by many successful projects for Iceberg implementations, including RisingWave, Lakekeeper, Spice AI, Apache DataFusion Comet, Databend, and many more. In the end, we’ll also have a demo on how to build a streaming Rust lakehouse using RisingWave to create Iceberg tables through the REST-based Lakekeeper catalog and query them with Doris to demonstrate the interoperability of the Apache Iceberg lakehouse.

As enterprises move toward AI-driven and agent-based architectures, the need for a scalable, real-time, and analytics-oriented data foundation becomes more critical than ever. In this session, I will share our experience in building an AI-ready data platform powered by Apache Doris, covering key architectural decisions, data accessibility, performance optimization, and operational scalability. Attendees will gain practical insights into how modern data platforms can accelerate decision-making, support AI and agentic workloads, and help organizations establish a foundation for the next generation of intelligent applications.

AI agents are only as good as the data they can access — and most data platforms weren't built for agents. I've spent the last year building real-time analytics pipelines on AWS: DynamoDB Streams → Kinesis → Firehose → S3 → Glue → Athena. For batch analytics and dashboards, this architecture works well. But as I started building AI agents that need to query operational data in real time, Athena started showing its limits. Athena's concurrency ceiling (20 concurrent queries by default), cold-start latency on small queries, and its inability to handle high-frequency agent queries without cost spiraling — these aren't bugs, they're design tradeoffs. Athena is a batch-oriented query engine dressed up as interactive. For agents that need to ask dozens of questions per second and get answers in under 500ms, that's the wrong tool. This session is an architectural evaluation talk: what AI agents actually demand from a data layer, where serverless query engines hit their limits, and why Apache Doris is purpose-built for exactly this use case. What I'll cover: 1. What AI agents need from data — specifically Agents aren't running monthly reports. They're asking: "What did this user do in the last 5 minutes?" "Has this transaction pattern appeared before?" "What's the current inventory level?" These are point queries and narrow scans at high concurrency, with latency budgets under 500ms. Most analytics engines are optimized for the opposite — wide scans, low concurrency, high throughput. 2. Where Athena and serverless query engines fall short for agent workloads Concurrency limits, query startup overhead, cost-per-query model at high frequency, inability to serve real-time ingested data without partition refresh delays — a concrete breakdown of where the serverless model breaks for agent-facing use cases. 3. Apache Doris as the agent-facing serving layer What makes Doris different: sub-second query latency, high concurrent query throughput, real-time data ingestion without batch refresh cycles, and native support for the mixed workloads agents generate (point lookups + aggregations + full-text search in the same query). How the Doris architecture — particularly its storage engine and vectorized execution — delivers what agents need. 4. The reference architecture Event pipeline (Kinesis/Kafka) → S3 lakehouse (raw + processed) → Apache Doris (real-time serving layer) → AI agent query interface. Where Doris fits alongside — not replacing — existing lakehouse infrastructure. When to keep Athena for historical batch queries and use Doris only for the agent-facing hot path. 5. Decision framework: when do you actually need Doris? Not every team needs this. A clear framework: query concurrency requirements, latency SLA, ingestion freshness requirements, and query pattern (wide scan vs point lookup) — mapped to when serverless is sufficient and when Doris becomes the right call. The goal is that attendees leave with a clear mental model of the agent-facing analytics problem, a reference architecture they can evaluate for their own stack, and an honest view of where Apache Doris earns its place in a modern data platform.

What if exploring data could be as simple as having a conversation? This session demonstrates how Amazon Quick AI agents can work with Apache Doris through the Model Context Protocol (MCP), turning natural-language questions into complex data queries and visual insights. Through a practical demo, the session will show how an AI agent understands a user's questions, interacts with Apache Doris via MCP, retrieves and analyzes data, and turns the results into clear visualizations. Instead of manually writing SQL or navigating multiple analytical tools, users can explore their data through a conversational interface while Doris handles the underlying analytical workloads. The session will walk through the end-to-end workflow, from asking questions in natural language to querying Doris and generating actionable insights, illustrating how MCP connects AI agents with high-performance analytical systems and makes data exploration more accessible, interactive, and efficient.

At Raiffeisen Bank Romania, AI agents are now real consumers of the analytics platform, and Apache Doris sits at its centre. This session shows how data and ML agents on ARIA (Artificial Raiffeisen Intelligence Agents), the bank's enterprise agentic AI platform, use Doris through MCP-based tools. The result is insights grounded in validated models rather than LLM guesswork. The core idea: ML decides, LLMs explain. Models produce governed, auditable predictions. ARIA agents explain them, combining model outputs and SHAP-based drivers into actionable recommendations for bankers. We then go under the hood: the reference architecture, the challenges of agents querying production data, security and controls on data MCPs, integration with data pipelines, and OpenMetadata as the semantic layer that agents rely on. Alin opens with the bank's AI platform landscape, the role of Doris in our data and ML agents, and why grounded agents matter. Adrian then covers the architecture, the challenges of agents interacting with data, data controls, pipelines and the semantic layer.

AI agents make database access more dynamic: a single agent may act on behalf of multiple users, while each request may require a different authorization decision. This creates new challenges for enforcing least-privilege access without putting application-specific policy logic around the database. This session walks through the authorization extension points in Apache Doris and shows how to build a custom Access Controller using the existing AccessControllerFactory SPI. The implementation uses OpenFGA as an external policy engine, while Apache Ranger serves as the in-tree reference implementation and comparison point. The session includes a live multi-user agent demo against a running OpenFGA store. Two end users access the same internal catalog through one agent, and a policy tuple is added during the demo to show the same query changing from allowed to denied. The OpenFGA store is then stopped to demonstrate how the controller fails closed when the external policy service is unavailable. The session also shows the resulting audit records and examines the trade-offs of putting external authorization checks on the query path, including policy consistency, caching, latency, and failure handling. You will leave with a practical view of how Apache Doris authorization can be extended beyond its built-in privilege model, how an external relationship-based policy engine such as OpenFGA can fit into the authorization flow, and which correctness, performance, and operational considerations to validate before taking a custom access controller into production.

C-level leaders want to explore new metrics, but they need answers that are both meaningful and fresh. Can an AI agent answer a live business question when the data is changing, metrics have multiple definitions, and the latest events may not yet be visible? This session presents a working Apache Doris pipeline for trustworthy real-time agent analytics. The goal is not only to generate a query, but to determine whether the result is semantically correct and current enough to trust. The workflow is: A user submits a free-text question. An LLM selects approved Doris MCP tools. MetricFlow resolves the governed metric and dimensions, then Doris executes the compiled query. Independent freshness and provenance checks determine whether the system should answer, request clarification, or block the response. The implementation was validated with: A 12-case evaluation matrix covering fresh metrics, product filters, churn, ambiguity, stale data, and wrong-metric attempts. All expected outcomes passing against independent ground truth. Complete traces containing prompts, model outputs, tool calls, compiled queries, execution results, freshness evidence, failures, latency, and cost. The session then explains how this architecture is designed to scale toward billions of events on GCP and how experimental Row Binlog and Table Stream features documented for Doris 5.0 and later could provide more database-native freshness tracking than the current application-managed approach.

AI agents increasingly need to understand relationships across thousands of enterprise tables, but traditional Text-to-SQL approaches struggle with complex, multi-hop relationships. In this talk, we will show how a PuppyGraph-powered agent automatically discovers entities, relationships, and semantics across thousands of tables to generate an ontology graph. PuppyGraph then queries the existing Apache Doris data directly as a graph—without ETL, data migration, or creating a second copy of the data. We will demonstrate how this architecture enables AI agents to combine SQL analytics with graph traversal for complex questions across large-scale enterprise data.

Discover how Tabsdata and Apache Doris can power an end-to-end event processing pipeline, from multi-source ingestion and sessionization to fast analytics and full-text search. By leveraging Apache Doris' inverted indexes, the solution brings event search and analytics into a single database, eliminating the need for a separate Elasticsearch instance and continuous synchronization across systems. A lightweight web interface built with React and FastAPI makes it easy for non-technical users to search customer activity, explore event sequences, monitor data quality metrics, and investigate anomalies with AI-assisted root cause analysis. This session demonstrates how a streamlined data stack can make event data more searchable, actionable, and accessible.