How KalamDB Works

Build a KalamDB application around a SQL schema: tables hold state, SDKs read and change it, and live queries keep the interface up to date.

SQL

1CREATE SCHEMA IF NOT EXISTS app;2CREATE TABLE app.todos (3  id BIGSERIAL PRIMARY KEY,4  title TEXT NOT NULL,5  completed BOOLEAN NOT NULL DEFAULT FALSE6) WITH (TYPE = 'USER');

The KalamDB application workflow

When you need to…	Use
Save and query application state	Tables and SQL
Update a screen when rows change	Live queries
Run trusted logic next to the data	Server procedures
Hand work to an independent worker	Topics and consumers
Use schema-aware client types	CLI code generation

A USER table isolates rows by the authenticated user. Use a SHARED table with policies when multiple users should collaborate. Use STREAM for temporary, user-scoped events with a TTL.

Common mistakes

A live query is a view of changing database state. A topic is a durable work stream with consumer acknowledgements. Use the first to render data and the second to process work that must survive worker restarts.

Next step

Run your first realtime app →

Reference: SQL, functions and generated SDKs.