Real-time SQL subscriptions for millions of clients — and AI agents too

Most chat applications today look like this:

Postgres
↓
Triggers
↓
Redis / Kafka
↓
WebSocket Server
↓
Connected Clients

And once scale grows… things become painful:

• expensive fan-out layers
• trigger complexity
• duplicated infrastructure
• hard user isolation
• difficult GDPR cleanup
• AI agents needing separate event systems

KalamDB takes a different approach.

The Shift: SQL + Pub/Sub in One Engine

KalamDB combines:

• SQL database
• real-time subscriptions
• WebSocket fan-out
• hot/cold storage
• per-user isolation

into a single engine.

Instead of adding Redis/Kafka beside your database…

your database itself becomes the real-time engine.

Traditional PostgreSQL Fan-Out Problem

Imagine a chat app.

A user sends one message:

INSERT INTO chat.messages (...)

Now the backend must:

1. store the message
2. publish event to Redis/Kafka
3. find subscribed users
4. push over WebSocket
5. notify AI agents
6. update unread counters
7. sync mobile/web clients

That fan-out layer becomes an entire distributed system.

KalamDB Approach

In KalamDB, subscriptions happen directly on SQL tables from the client app, Client app sends for example this query:

1SUBSCRIBE TO chat.messages2WHERE conversation_id = 13OPTIONS (last_rows = 20);

Then the client immediately receive inserts/updates/deletes in real time over WebSockets.

PostgreSQL → KalamDB Fan-Out Architecture

Here’s the interesting part 👇

PostgreSQL can still remain your transactional source.

But every DML event can fan out into KalamDB subscriptions.

PostgreSQL
│
INSERT / UPDATE / DELETE
│
PG Kalam extension
│
▼
KalamDB
(Realtime SQL Engine)
│

▼

Mobile Apps Web Apps AI Agents

This gives you:

✅ PostgreSQL ecosystem
✅ Real-time subscriptions
✅ scalable WebSocket fan-out
✅ AI event streaming
✅ user isolation

Why Per-User Storage Changes Everything

Traditional databases keep all messages in one giant table:

messages
---------
user_id
conversation_id
content

Every subscription scans/filter the same shared table.

KalamDB instead isolates user data physically.

user1.messages
user2.messages
user3.messages

That means:

• subscriptions become cheap
• fan-out becomes localized
• GDPR deletion is trivial
• AI agents can subscribe per-user or globally
• noisy users don’t affect others

Targeting Specific Users Instantly 🎯

KalamDB also supports writing “as” another user

This is powerful for:

• notifications
• AI replies
• system messages
• inbox delivery
• agent-generated content

1EXECUTE AS 'user-1' (2INSERT INTO chat.messages3VALUES (...)4);

This allows a backend service or AI agent to directly publish into a specific user’s isolated storage.

Real-Time Chat with AI Agents 🤖

Now things become very interesting.

An AI agent can consume all incoming messages from all users — including typing events and user presence updates:

Or even consume events from specific shards/storage groups in the future architecture roadmap.

The AI agent now behaves like a live participant inside the system:

User sends message
↓
KalamDB publishes event into topic
↓
AI agent consumes event instantly
↓
AI generates response
↓
AI inserts message back into user stream
↓
Clients receive live update

Stream Tables for Typing / Presence / AI Thinking ⚡

KalamDB also supports ephemeral STREAM tables.

Perfect for:

• typing indicators
• online presence
• AI “thinking…”
• temporary events
• cancel/retry signals

1CREATE TABLE chat.typing_events (2  id BIGINT PRIMARY KEY DEFAULT SNOWFLAKE_ID(),3  conversation_id BIGINT,4  user_id TEXT,5  event_type TEXT,6  created_at TIMESTAMP DEFAULT NOW()7) WITH (8  TYPE = 'STREAM',9  TTL_SECONDS = 3010);$0

Subscribe:

1SUBSCRIBE TO chat.typing_events2WHERE conversation_id = 1;$0

Now every client receives live typing updates instantly even if the user have number of clients connected with the same authentication they all will be updated in real-time.

TypeScript & React Realtime Example ⚡

KalamDB already ships with a TypeScript SDK that supports realtime live queries over a shared WebSocket connection.

1import { createClient } from '@kalamdb/client';2 3const client = createClient({4  url: 'http://localhost:8080',5});6 7const unsubscribe = await client.live(8  `9    SELECT *10    FROM chat.messages11    WHERE conversation_id = 112    ORDER BY created_at ASC13  `,14  (rows) => {15    console.log('Live rows:', rows);16  }17);

And here is an example using react component:

1const client = getExampleClient();2 3export function InboxPane({ conversationId }: { conversationId: string }) {4  return (5    <KalamProvider client={client}>6      <LiveQueries7        queries={{8          conversations: {9            table: conversations,10            orderBy: (table) => desc(table.updatedAt),11            limit: 20,12          },13          messages: {14            table: messages,15            where: (table) => eq(table.conversationId, conversationId),16            orderBy: (table) => asc(table.createdAt),17            deps: [conversationId],18          },19        }}20        deps={[conversationId]}21      >22        {({ conversations, messages, state }) => (23          <ChatLayout24            conversations={conversations.rows}25            messages={messages.rows}26            busy={state.loading}27          />28        )}29      </LiveQueries>30    </KalamProvider>31  );32}

Just SQL + live rows.

Why This Matters for AI Applications 🤖

AI systems are fundamentally event-driven.

Agents need:

• live user messages
• realtime typing/thinking states
• memory updates
• tool outputs
• notifications
• collaborative events
• streaming context

KalamDB simplifies this into:

SQL + Live Queries + Topics + Consumers

That dramatically changes how realtime systems are built.

AI Agents as Live Participants

An AI agent can consume events directly from a topic:

CONSUME FROM chat.messages;

Or only consume events for a specific user:

CONSUME FROM chat.messages
WHERE user_id = 'user_123';

The AI becomes another realtime participant in the system:

User sends message
↓
KalamDB publishes event
↓
AI agent consumes instantly
↓
AI generates response
↓
AI inserts response into chat.messages
↓
Frontend receives live update immediately

One data plane.
One subscription engine.
One SQL layer.

Example End-to-End Flow 🌍

1. User sends message
2. PostgreSQL transaction commits
3. PG Kalam extension
4. KalamDB fans out changes instantly
5. Mobile/Web clients receive live updates
6. AI agents consume the same event stream
7. AI responds with SQL INSERT
8. KalamDB publishes the response live to all connected clients

No duplicated infrastructure.
No polling loops.
No custom fan-out layer.

The Bigger Vision

I believe future applications will expose live user-scoped data directly to AI agents.

Not through dozens of APIs and fragile tool chains.

But through:

SELECT ...
CONSUME FROM ...
INSERT ...

The same SQL backend becomes shared between:

• web apps
• mobile apps
• backend services
• AI agents
• workflows
• realtime consumers

That’s where KalamDB is heading.