About this session
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.
