Streaming-first databases now serve fresh SQL results in 10-20 ms p99 and under 100 ms pipelines for live agent feeds at scale. Full breakdown.
What streaming-first means for agent feeds
Agent feeds need continuous, correct answers—not batch snapshots that go stale while a model is still reasoning. A streaming-first database treats change as the primary input: inserts, updates, and deletes flow in, and queries stay live as derived results. Instead of re-running a full SQL statement on a timer, the engine maintains incremental state so each event updates only what that event affects. For agent loops that poll tools, watch tools, or push tool results into a shared context, that model matches the workload: small deltas, frequent reads, and a requirement that “current” means recent enough to act on.
The latency targets that matter here are tight. Serving fresh SQL results in the 10–20 ms p99 range keeps tool calls inside a single interactive step. Keeping end-to-end pipelines under 100 ms leaves headroom for serialization, network hops, policy checks, and the model’s own turn time. Those budgets only hold if the database path is incremental and the feed path avoids full recomputation on every tick.
Pipeline shape: from events to feed items
A practical agent-feed pipeline has three stages. First, capture domain events—task status, tool outcomes, memory writes, retrieval hits—with stable keys and ordered timestamps. Second, materialize or maintain SQL views that answer feed questions: “open tasks for this session,” “latest tool result per agent,” “errors since last handoff.” Third, project those rows into feed items (title, body, severity, links) and push them to subscribers. Streaming-first systems collapse the second stage into continuous query maintenance so the third stage can emit only on real change.
- Prefer keyed streams so late or duplicate events update one logical row instead of appending noise.
- Keep feed projections thin: store facts in SQL, render copy at the edge so rewrites do not force re-ingestion.
- Separate “authoritative state” from “notification fan-out” so a slow subscriber never blocks query freshness.
SQL freshness without full rescans
Classic request/response SQL assumes a quiet table and a full plan per query. Agent feeds invert that: many concurrent sessions, overlapping predicates, and almost continuous mutation. Streaming-first engines maintain operator state—joins, aggregations, filters—so a new event walks a narrow path through the plan. Freshness is then a property of that path’s latency, not of how often you schedule a job. When p99 result freshness sits in the 10–20 ms band, agents can safely treat a SQL read as a live sensor rather than a cache that might lag by minutes.
Design queries for incremental maintenance. Prefer equi-joins on stable keys, bounded windows over unbounded full history, and aggregates you can update with +/− deltas. Avoid patterns that force global reshuffles on every write. If a view cannot be maintained cheaply, split it: a fast stream-backed core for the feed, and a slower analytical path for rare deep queries.
Scaling live feeds without breaking the budget
Scale pressure shows up as fan-out and state size, not raw QPS alone. Partition by session, tenant, or agent so each shard owns a bounded working set. Cap retained history for hot views; move cold history to storage that is not on the critical path. Backpressure should drop or batch notifications—not stall ingestion—so under-100 ms pipelines stay intact when one consumer lags. Measure the full path: event in → view update → feed emit → client ack. The database number is only one slice; serializers, auth, and multi-region hops often dominate if left unexamined.
Operationally, treat feed schemas as contracts. Version feed item shapes, document which fields are eventually consistent versus strongly fresh, and give agents a monotonic cursor so reconnects do not replay the world. Streaming-first databases earn their place when they make that contract cheap: low p99 SQL freshness, pipeline latency under 100 ms, and room for the agent stack to do real work between updates.