SQL Overview

xcon-db executes a lean subset of SQL over its three table families — timeseries, rows and kv. Standard SQL is accepted at the interface; anything outside the subset gets a clean error instead of a slow surprise. There is no general relational optimizer and there are no joins — leanness lives in what the engine refuses to execute.

Statements

Statement	Purpose
CREATE TABLE	Declare a timeseries table, its channels and policies
CREATE ROWS TABLE	Declare a current-state rows table (engine-generated id)
CREATE KV TABLE	Declare a key→value table (SET/GET/DEL over SQL, optional TTL)
ALTER TABLE	Add, tune, rename or drop columns (no type changes)
DROP TABLE	Remove a table and its data
TRUNCATE TABLE	Empty a table's data, keep its declaration (and snapshots)
INSERT	Append observations; on rows tables, mint a new row; on kv tables, SET (upsert)
UPDATE	Partial write to a rows-table row (AND x_rev = N = optimistic push)
SELECT	Range scans, LATEST ON, ordering, limits; current rows on rows tables; GET/scan on kv
SAMPLE BY	Downsampling with FILL(PREV|NULL|LINEAR)
DELETE	Tombstone an entity (timeseries, mutable); soft-delete a row (rows); DEL a key (kv)
PROFILE <statement>	Run the statement with stage spans on, answer with the span tree
CHECKPOINT	Seal for backup
SHOW TABLES/COLUMNS	The schema, honestly
SHOW LOGS/SESSIONS	The operator's window
SHOW REVISIONS / RECORD REVISION	The migration journal
BEGIN/COMMIT/ABORT MIGRATION	Atomic migration — all or nothing
SNAPSHOT / RESTORE / SHOW SNAPSHOTS	Copy-free rows-table snapshots (rows)
VACUUM	Purge a rows table's tombstone traces, raise its sync horizon
CREATE/DROP DATABASE, … USER	Node management (admin)
ALTER DATABASE SET DURABILITY, SHOW DURABILITY	Strict (default) or relaxed write durability

Literals & durations

• strings: single quotes, '' escapes — 'door ''open'''
• numbers: 42, -3.5
• NULL, true/false (booleans are just 1/0 — the type system is f64+string; BOOL and INT are catalog views over f64)
• durations: <number> [ms|s|m|h|d] — 60 s, 90 d, bare numbers are milliseconds
• -- starts a comment

WHERE

On a timeseries table, exactly two predicates exist, combined with AND (a rows table filters by xid = '...' and/or one column comparison — = on any column, >/>=/</<= on a numeric one; a kv table filters by key = '...' only):

• entity = '<string>'
• ts comparisons: >=, >, <=, <, =, BETWEEN a AND b (ts is Unix milliseconds)

That is not a placeholder for a future expression engine; value predicates belong in your code or your dashboard tool.