SQL Workflows
Many CLI workflows are plain SQL through -c, -f, or the interactive shell. Backslash commands cover CLI-managed operations; this page covers SQL-first workflows.
Follower write forwarding
KalamDB uses Multi-Raft groups — a client can send a write to any reachable node.
Assume effective user user-42 hashes to DataUserShard(7):
- Request lands on node 2 even if it is a follower for that shard.
- KalamDB classifies SQL and derives the target Raft group from table type and
user_id. - User/stream tables route by hashing
user_idintocluster.user_shardsgroups. - Non-leader nodes forward SQL, params, auth, and request id over gRPC to the group leader.
- Leader executes, replicates, commits, and returns the result.
The client does not need to discover the leader first.
Multi-Raft routing today
- One metadata Raft group plus multiple user data groups.
- User/stream data routes by
user_idfor write-path locality. - Shared tables route to a single shared data group today; partition-by-key is planned.
See clustering and table types.
Impersonation
Or the \as shortcut — see Interactive Commands.
Backup and restore
- Paths resolve on the server filesystem, not the CLI machine.
.tar.gz/.tgz→ single archive; otherwise directory layout.- Requires DBA or System role.
- Track status:
SELECT * FROM system.jobs WHERE job_id = 'backupjob';
Export user data
SHOW EXPORT returns download_url paths like /v1/exports/<user_id>/<export_id>. Prefix with your server base URL when downloading.
Table export/import (meta-commands)
Live queries
Same SELECT you would run normally — no separate live-query keyword:
Topic pub/sub SQL
Use --consume / \consume for terminal convenience; use SQL when scripting explicit offset control.
Related
Last updated on