Vector Search in Streaming Databases: Real-Time Similarity at Scale
AI agents need persistent memory — a record of past interactions, current context, and accumulated knowledge that persists across conversations. A streaming database serves as the agent memory layer: materialized views that continuously aggregate agent interactions into queryable state.
Agent Memory Architecture
User interactions ──→ Kafka ──→ RisingWave
│
┌──────────┴──────────┐
↓ ↓
Short-term memory Long-term memory
(session context MV) (historical aggregation MV)
│ │
└──────────┬──────────┘
↓
Agent queries via PG
Implementation
-- Short-term: current session context
CREATE MATERIALIZED VIEW agent_session AS
SELECT user_id, session_id,
array_agg(message ORDER BY ts) as conversation_history,
last_value(intent ORDER BY ts) as current_intent,
COUNT(*) as turns
FROM agent_interactions
WHERE ts > NOW() - INTERVAL '30 minutes'
GROUP BY user_id, session_id;
-- Long-term: user preferences and history
CREATE MATERIALIZED VIEW agent_memory AS
SELECT user_id,
COUNT(DISTINCT session_id) as total_sessions,
array_agg(DISTINCT topic) as discussed_topics,
last_value(sentiment ORDER BY ts) as last_sentiment
FROM agent_interactions GROUP BY user_id;
Frequently Asked Questions
Why not store agent memory in PostgreSQL?
PostgreSQL stores static data. A streaming database continuously processes interaction events and maintains pre-aggregated memory views in real time — no batch jobs needed to update memory.
How does this compare to LangChain memory?
LangChain memory stores conversation history in-process or in Redis. Streaming database memory persists across sessions, aggregates across interactions, and is shared across agent instances.

