What KDBS is not

KDBS is an OLTP engine, not a general-purpose one. It leaves out features that would make a statement’s cost unpredictable or give one thing two spellings, and it says so with an error instead of accepting the statement and doing something else. If your workload is analytical scans over long history, use a column store. If it is frequent transactional access to current data that must obey rules, KDBS is built for that.

Workloads it is not for

Workload	Why not
Analytics and data warehousing	No CTEs, derived tables, window functions or HAVING. A full scan costs about twice what PostgreSQL’s does per row, measured on one host (see Known gaps).
Ad-hoc reporting with complex SQL	The grammar is small on purpose: joins are inner equi-joins run in the order written, and WHERE conditions combine only with AND.
Serving clients over a network	The server listens on loopback (127.0.0.1) only, so clients run on the same host. TLS and SCRAM authentication exist but are off by default.
Long-running transactions	An explicit transaction is rolled back once it exceeds txn_lifetime_ceiling_ms (60 s by default).
Replicated or highly available deployments	There is no streaming standby, and no logical dump.

SQL it refuses on purpose

Every refusal carries the byte position of the offending token. NOT_IMPLEMENTED means the design admits the form and this release has not built it. UNSUPPORTED means the engine’s design cannot admit it, so the statement must be rewritten. See Refusals.

Left out	Reason
CTEs (WITH) and subqueries in FROM	The inner result would have to become a temporary relation, which breaks direct primary-key probing into the next step. Subqueries are allowed in WHERE.
Window functions	An analytical feature; KDBS makes no attempt to be a data warehouse.
Expressions in a select list or WHERE	A smaller grammar that always runs predictably was chosen over a larger one. Expressions are allowed in UPDATE … SET.
OR and NOT over conditions	Same reason. Conditions combine with AND.
Outer joins (LEFT, RIGHT, FULL)	Not built. The words are reserved so the grammar will not change if they land.
HAVING, and ORDER BY over grouped results	Kept as one open decision. Filter before grouping with WHERE, or filter the result in the client.
A cost-based planner	The plan is fixed when the statement is parsed and never changes with table size. This is what lets a pattern_id name one plan. See Statements and execution plans.
Query rewrites and decorrelation	The order you write is the order that runs; it is part of the contract with the client.
UNIQUE indexes	An index speeds up reads and must never make a write fail. See CREATE INDEX.
float	Its comparison and rounding rules do not fit an engine that keeps values exact. Use decimal(p, s). See Data types.
Updating a primary key	The key is the row’s identity, not a field of it. See Row identity and primary keys.
SERIAL, AUTO_INCREMENT, IF NOT EXISTS, public., FROM t a without AS	Each would be a second spelling of something that already has one. An INSERT that leaves out the key already gets an issued id.
Escaping a quote inside a string literal	Same reason as above.
Data-moving ALTER TABLE	ALTER TABLE only renames. See ALTER TABLE, DROP TABLE.
CREATE TABLE ... HEAP	New tables are B+ trees only, so that storage form can mature first.
Savepoints and nested transactions	Not offered.
Cursors	A reply streams whole. Page with WHERE id > <last seen> LIMIT n. See SELECT.

Storage and operations it does not do

• The data file never shrinks. Pages of a dropped table are reused, but nothing returns space to the file system, and no VACUUM moves live rows.
• No incremental, compressed or encrypted backup, no parallel copy, no object-storage target. See Back up and restore.
• Point-in-time recovery targets a log position, not a time, because the commit record carries no time.

Not production-hardened yet

KDBS v3.0.0 is under active development. Read Known gaps before you rely on it: it lists what is missing and what a restart loses.

See also

• What is KDBS?
• SQL language overview
• Limits