Table DDL
KalamDB supports three application table types: USER, SHARED, and STREAM. For the full
architecture, access matrices, storage behavior, and when to choose each type, see
/docs/server/architecture/table-types.
CREATE TABLE
Syntax
Table options are type-specific:
USER:STORAGE_ID,USE_USER_STORAGE,FLUSH_POLICY,COMPRESSIONSHARED:STORAGE_ID,FLUSH_POLICY,COMPRESSIONSTREAM:TTL_SECONDS,EVICTION_STRATEGY,MAX_STREAM_SIZE_BYTES
Shared tables always use FORCE row-level security. Creating a shared table without
CREATE POLICY is default-deny for user and service
(zero rows on SELECT; writes fail). system and dba bypass RLS. ACCESS_LEVEL is not a table
option.
For storage-specific options such as STORAGE_ID and USE_USER_STORAGE, see
/docs/server/sql-reference/storage-id-usage. For
flush behavior, see /docs/server/architecture/storage-tiers.
COMPRESSION accepts only none, snappy, and zstd, and is valid only for USER and SHARED
tables. It controls the Apache Parquet codec used when table data is flushed or compacted into
cold-storage segments. none writes uncompressed Parquet pages, snappy is the default and
optimizes for low CPU overhead, and zstd uses Zstandard level 1 for better compression density with
modest extra CPU. This option is not WebSocket gzip and does not change RocksDB hot-tier
compression. STREAM tables use hot stream log storage and do not accept table Parquet compression.
Examples
User table (per-user isolated):
Shared table (global rows, FORCE RLS):
Stream table (ephemeral with TTL):
ALTER TABLE
Equality indexes on USER and SHARED tables use parentheses, not USING COSINE:
See Indexes for prefix seeks, uniqueness, and membership-policy patterns. Vector indexes stay on Vector Search.
SET TBLPROPERTIES supports the same type-specific persisted options as CREATE TABLE.
Use FLUSH_POLICY = NULL to clear a user/shared flush policy.
Examples:
Vector index example
After the index exists, rank nearest rows with:
DROP TABLE
Grant shared-table rows with CREATE POLICY, not table
options.
CREATE VIEW
Example:
SHOW TABLES
DESCRIBE TABLE
Returns full schema-registry metadata (column_id, is_primary_key, schema_version, Kalam
data_type names, and more).
For the DataFusion-style shorthand (DESCRIBE namespace.table), CLI \d behavior, and
EXPLAIN / EXPLAIN ANALYZE VERBOSE plan inspection, see
/docs/server/sql-reference/diagnostics.
SHOW STATS
More Table Architecture
- /docs/server/architecture/table-types
- /docs/server/sql-reference/indexes
- /docs/server/sql-reference/types
- /docs/server/architecture/storage-tiers
- /docs/server/architecture/manifests
- /docs/server/architecture/live-query
Constraints and schema evolution
Use NOT NULL, defaults and a primary key for application columns. PostgreSQL-shaped declarations and catalog metadata do not guarantee PostgreSQL constraint enforcement. In the tested 0.8 server, table CHECK, secondary UNIQUE and foreign-key declarations were accepted but did not reject violating writes. Do not rely on them as integrity boundaries; use validated application/routine writes and enforced domain checks where appropriate. A primary key is optional: a table without one gets a hidden _row_id, omitted by SELECT *. Use an explicit ID for application row references.
A new column default supplies a value to existing rows; later default changes affect new writes rather than rewriting historical values. Changing a column type converts existing rows with USING. Coordinate schema changes with live clients: incompatible DDL disconnects subscriptions, which must reconnect against the committed schema.
See sequences and generated IDs and transactions.