user_alice.messagesuser_bob.ordersuser_diana.notestenant_c.eventstenant_acme.invoicestenant_nw.shipmentsuser_alice.agent_memorychat.events_topicuser_bob.embeddingstenant_c.filesCREATE TABLE ... WITH (TYPE='USER')Give AI agents one SQL tool to your app data.
KalamDB gives each user or tenant a private SQL state layer, then streams row-level changes to agents, dashboards, and frontend UIs over live subscriptions.
- One tool
- execute_sql_query
- Isolation
- USER tables
- Live state
- WebSocket rows
Simple SQL + live subscriptions
Give agents familiar SQL for writes and reads, then let product surfaces subscribe to the same row set without polling or another synchronization service.
import { KalamProvider, LiveQueries } from '@kalamdb/react';
import { asc, desc, eq } from 'drizzle-orm';
import { getExampleClient } from './client';
import { conversations, messages } from './schema.generated';
const client = getExampleClient();
export function InboxPane({ conversationId }: { conversationId: string }) {
return (
<KalamProvider client={client}>
<LiveQueries
queries={{
conversations: {
table: conversations,
orderBy: (table) => desc(table.updatedAt),
limit: 20,
},
messages: {
table: messages,
where: (table) => eq(table.conversationId, conversationId),
orderBy: (table) => asc(table.createdAt),
deps: [conversationId],
},
}}
deps={[conversationId]}
>
{({ conversations, messages, state }) => (
<ChatLayout
conversations={conversations.rows}
messages={messages.rows}
busy={state.loading}
/>
)}
</LiveQueries>
</KalamProvider>
);
}How KalamDB works
USER tables isolate each tenant, KalamDB commits state through a SQL-first runtime, and live subscriptions fan out the exact row set to agents and interfaces.
PostgreSQL connects to a running KalamDB server through pg_kalam.
PostgreSQL keeps SQL parsing, planning, and the local relation surface. The pg_kalam extension reads the foreign server definition, mirrors CREATE TABLE ... USING kalamdb, and forwards scans and DML to KalamDB.
PostgreSQL parses and plans the query against the local table surface.
pg_kalam resolves the foreign server settings and tenant session context.
Mirrored DDL, reads, and writes are forwarded to the KalamDB server.
Rows come back as PostgreSQL tuples while KalamDB stays the source of truth.
See the PostgreSQL extension architecture docs for the full remote-mode flow.
CREATE EXTENSION pg_kalam; CREATE SERVER kalam_server FOREIGN DATA WRAPPER pg_kalam OPTIONS ( host '127.0.0.1', port '2910' ); CREATE TABLE app.messages ( id BIGINT PRIMARY KEY DEFAULT SNOWFLAKE_ID(), room TEXT, content TEXT) USING kalamdb;Features for agent-native data apps
Everything an agent product normally stitches together: private user state, SQL access, live rows, topics, admin tooling, and durable storage built around tenant boundaries.
Per-tenant isolation — no app-side filters
Every user gets a private tenant partition. The same SQL can run for every account, and USER tables still return only that caller's rows. No app-side WHERE user_id = ? glue.
See runnable examples →Topics + Pub/Sub streams
Publish events to topics and subscribe from any client or agent. Replay events and use consumer groups when you need them.
See topic pub/sub docs →Live queries with materialized rows
Use live() to stream the current row set for messages, memory, dashboards, and tool logs without writing your own diff reconciler.
See live query docs →Bring your own storage
Store old history in S3, Azure Blob, GCS, or local disk. Keep hot data fast and move cold data to cheaper storage.
See storage tiers docs →Scales by user + efficient cold storage
Isolation creates natural shards per user. Older history can compact into compressed files in object storage for lower cost and faster scans.
See cold storage guide →High availability clustering (Raft)
Run a Raft cluster with leader election and failover, so chat and subscriptions stay online.
See clustering docs →Fast and steady performance
Low-latency writes and steady throughput for chat and high-volume agent events. Built in Rust.
See benchmark docs →End-to-end encryption (client-side)
Encrypt agent memory before it leaves your app. KalamDB stores only encrypted data. The server never sees plaintext. You hold the keys.
See security guide →Admin UI: SQL Studio, Live Data and more
Web Admin UI for instances, users, and streams. Run SQL in SQL Studio, turn on Live query, browse topics, and explore per-user namespaces.
See Admin UI docs →CLI tool (kalam)
Postgres-style CLI for local and cloud instances. Connect, query, subscribe, export data, and manage users from one binary.
See CLI docs →Built with Rust, Arrow, DataFusion, Parquet, and Postgres
Admin UI + CLI for the whole data loop
Operate KalamDB like a serious database company product: inspect live rows, query tenant scopes, manage users, and automate workflows from the browser or terminal.
Admin UI — SQL Studio & Live Data
LiveA web admin console that ships with every instance. Browse namespaces, inspect tables, and run SQL in the built-in SQL Studio. Turn on Live query to make anySELECT stream updates as rows change. Explore topics and per-user data without writing app code.
CLI — Interactive Database Terminal
LiveA Postgres-style terminal for local and cloud instances. Connect, query, subscribe, export user data, and manage users from one binary. It includes history, \info, and tab-completion. Great for scripts and CI.
Give AI agents one SQL tool to your app data.
Start with the open-source runtime, keep tenant data isolated by default, and stream live state to agents and product surfaces without another backend layer.


