Schema Watch
KalamDB supports two schema watch workflows. They solve different problems — use the one that matches how your schema changes.
| Mode | Entry point | Watches | Best for |
|---|---|---|---|
| File watch | kalam dev | schema.sql on disk | Local development with kalam.toml projects |
| Remote poll | kalam --watch-schema | system.tables on the server | Any DDL applied outside your repo (admin UI, another CLI session) |
File watch (kalam dev)
This is the default for KalamDB projects. Enable both flags in kalam.toml:
Then run:
Behavior
- Poll
schema.sqlevery 2 seconds - On modification, debounce until the file is stable (handles editor save bursts)
- Diff against
kalam/.schema-baseline.sqland updatekalam/migrations/_draft.sql - Apply pending numbered migrations
- Regenerate TypeScript/Dart artifacts when
generate_types = true - Prompt to apply the draft (unless
kalam dev --force, which skips the modal — you still seal/apply through the prompt’s Apply path orkalam migration seal)
The watch loop runs alongside managed processes ([dev.processes]). Schema failures pause only the schema pipeline — other service logs keep streaming.
See Local Development and Migrations for the full pipeline.
Remote poll (kalam --watch-schema)
Legacy standalone mode for server-side schema changes. Requires --run:
Use when DDL runs directly against KalamDB (not through your local schema.sql) and you need a shell command to rerun after metadata changes.
Options
| Option | Description |
|---|---|
--watch-schema | Enable remote polling mode |
--namespace <NAME> | Limit to namespaces (repeatable) |
--table <namespace.table> | Limit to tables (repeatable) |
--run <COMMAND> | Shell command after changes (required) |
--run-on-start | Run command once before polling |
--interval <DURATION> | Poll interval (default 5s; 500ms, 2s, 1m) |
Examples
How remote polling works
The CLI queries system.tables and checks for rows whose updated_at is newer than the last observed timestamp. Namespace and table filters combine with OR.
This mode does not read kalam.toml, manage migrations, or start child processes. For full project workflows, prefer kalam dev.