Store messages, agent memory, embeddings, and tool logs. USER tables keep every query inside the signed-in user boundary, while `live()` streams current rows to browsers and agents in realtime. Run vector search with SQL, then keep recent data fast and move older history to cheaper storage.
curl -fsSL https://kalamdb.org/install.sh | bash
import { createClient, Auth, SeqId } from '@kalamdb/client'; const client = createClient({ url: 'http://localhost:8080', authProvider: async () => Auth.jwt('<ACCESS_TOKEN>'),}); const resumeFrom = SeqId.from('7262216745594062848'); const stopMessages = await client.live( `SELECT id, room, role, content, created_at FROM chat.messages`, (rows) => { // `chat.messages` can be a USER table. // The same query runs for every signed-in customer, but KalamDB only // returns that caller's rows. renderRows(rows); }, { subscriptionOptions: { last_rows: 200, from_seq_id: resumeFrom.toJSON(), }, },); await client.query( 'INSERT INTO chat.messages (room, role, content) VALUES ($1, $2, $3)', ['main', 'user', 'hello from the browser']);See how frontend queries, PostgreSQL workflows, and live updates flow through the KalamDB runtime.
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 '9188' ); CREATE TABLE app.messages ( id BIGINT PRIMARY KEY DEFAULT SNOWFLAKE_ID(), room TEXT, content TEXT ) USING kalamdb;
Keep each user or tenant in their own data space. Query USER tables directly, stream materialized rows in realtime, use topics for pub/sub, and move old history to object storage when you need to scale.
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.
Read more →Publish events to topics and subscribe from any client or agent. Replay events and use consumer groups when you need them.
Read more →Use live() to stream the current row set for messages, memory, dashboards, and tool logs without writing your own diff reconciler.
Read more →Store old history in S3, Azure Blob, GCS, or local disk. Keep hot data fast and move cold data to cheaper storage.
Read more →Isolation creates natural shards per user. Older history can compact into compressed files in object storage for lower cost and faster scans.
Read more →Run a Raft cluster with leader election and failover, so chat and subscriptions stay online.
Read more →Low-latency writes and steady throughput for chat and high-volume agent events. Built in Rust.
Read more →Encrypt agent memory before it leaves your app. KalamDB stores only encrypted data. The server never sees plaintext. You hold the keys.
Read 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.
Read more →Postgres-style CLI for local and cloud instances. Connect, query, subscribe, export data, and manage users from one binary.
Read more →No custom language to learn. Write standard SQL to create tables, save state, and subscribe to live updates. Keep hot data on local disk and store long-term history in object storage.
CREATE TABLE agent.messages ( id BIGINT DEFAULT SNOWFLAKE_ID(), role TEXT, content TEXT, user_id TEXT, created TIMESTAMP ) WITH (TYPE='USER');
Agent writes can enter through PostgreSQL with pg_kalam, land in KalamDB, and fan back out to live subscribers in realtime.
An agent or backend worker writes memory, tool output, or chat state into PostgreSQL.
The pg_kalam extension resolves the foreign server and forwards that write into KalamDB.
KalamDB becomes the source of truth, keeping recent rows hot and moving older history to lower-cost storage when needed.
Materialized query updates stream over WebSocket to matching apps, dashboards, and agents.
The next agent step reads the newest committed row set and continues from the same shared state loop.
KalamDB is more than chat messages. Inside each user space, store tables, vectors, and file records so your agents can find what they need fast.
Store file metadata, ownership, and processing status in user tables.
Store embeddings in SQL tables and rank similar rows with vector search.
Model messages, tool calls, checkpoints, and your app data as SQL tables.
Add indexes for fast lookups as your agent workload grows.
Per-user chat threads with materialized live rows, resume checkpoints, and full history replay.
Store tool calls, checkpoints, and agent state in durable per-tenant tables.
Store embeddings alongside documents and files, then find the nearest rows with SQL vector search.
Agents pause for approval, humans respond, and agents resume. Every step is saved in a private per-user history.
Live metrics, monitoring feeds, and notification streams with row-materialized SQL subscriptions.
Ship one codebase for every customer. USER tables keep each tenant in its own partition, so the same query only returns that tenant's data.
Shared docs, boards, and multiplayer state with instant sync.
KalamDB includes a web Admin UI and an interactive CLI. Explore data, run SQL, subscribe to live streams, and manage users without extra tools.
A 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.
A 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.
One SQL-first realtime database for user isolation, agent collaboration, and live subscriptions. Start building in minutes.
