Choosing KalamDB Table Types

Choose a KalamDB table by who should see its rows and how long its data should live.

Table	Use for	Example
`USER`	Private per-user data	Notes, personal inbox
`SHARED`	Collaborative data with policies	Teams, chat rooms
`STREAM`	Short-lived, user-scoped realtime data	Temporary progress, transient events

Create a private KalamDB table

Run this as an account allowed to create tables, or add it to your project’s schema:

SQL

1CREATE SCHEMA IF NOT EXISTS app;2 3CREATE TABLE app.todos (4  id BIGSERIAL PRIMARY KEY,5  title TEXT NOT NULL,6  completed BOOLEAN NOT NULL DEFAULT FALSE7) WITH (TYPE = 'USER');8 9INSERT INTO app.todos (title) VALUES ('Build my first realtime app');10SELECT * FROM app.todos;

Expect one row in your current user’s scope, with completed set to FALSE. Another authenticated user sees their own rows. You do not need to add a user_id predicate to every query.

When to choose SHARED or STREAM

Use SHARED when people need to see the same rows. Configure policies deliberately: regular users and services need a matching policy, while administrative roles bypass RLS.

Use STREAM for temporary events. Specify TTL_SECONDS at creation. STREAM rows are user-scoped; a stream is not automatically a shared broadcast channel.

Common mistakes

Test isolation with two normal users, not only with an administrator. A USER table read follows the effective identity even for root. A SHARED table needs policies before ordinary users can access its rows.

Next step

Query and modify your todos →

Reference: Table creation and options.