SQL Statements

This page summarizes the user-facing SQL statement families available in v0.1. PostgreSQL compatibility is implemented incrementally, so use this as a guide rather than a complete SQL grammar.

Query statements

SELECT id, title
FROM docs
WHERE kind = 'runbook'
ORDER BY id
LIMIT 10;

Supported query features include ordinary projections, filters, ordering, limits, joins, aggregates, and selected window functions. Complex PostgreSQL syntax should be tested against your workload.

Data definition

CREATE TABLE items (
    id INT PRIMARY KEY,
    name TEXT NOT NULL,
    embedding VECTOR(3)
);

CREATE INDEX items_name_idx ON items (name);
CREATE INDEX items_embedding_idx ON items USING hnsw (embedding);

DROP INDEX items_name_idx;
DROP TABLE items;

Common DDL paths include tables, indexes, views, sequences, node labels, and edge labels. Some ALTER TABLE paths are implemented, but alpha users should validate the exact operation they need.

Data manipulation

INSERT INTO items VALUES (1, 'alpha', '[1.0,0.0,0.0]');
UPDATE items SET name = 'beta' WHERE id = 1;
DELETE FROM items WHERE id = 1;

RETURNING, defaults, ON CONFLICT, and COPY-related paths exist in the codebase, but compatibility details should be tested before relying on generated SQL from an ORM.

Transactions

BEGIN;
SAVEPOINT before_change;
ROLLBACK TO SAVEPOINT before_change;
RELEASE SAVEPOINT before_change;
COMMIT;

See Transactions for guidance.

Roles and privileges

CREATE ROLE reader LOGIN;
GRANT SELECT ON items TO reader;
REVOKE SELECT ON items FROM reader;
DROP ROLE reader;

Roles, grants, revokes, and superuser-style paths are part of the security model. The v0.1 docs still recommend local evaluation rather than exposed production use.

Graph DDL

CREATE NODE LABEL person ON persons;
CREATE EDGE LABEL friends ON friends SOURCE person TARGET person;

DROP EDGE LABEL friends;
DROP NODE LABEL person;

See Graph Reference.

Explain

Use EXPLAIN and EXPLAIN ANALYZE where supported to inspect execution shape during performance work.

Statement coverage map

The parser accepts a large surface area for PostgreSQL compatibility. Acceptance by the parser does not imply full execution semantics — for compatibility-only families the engine validates the AST and returns the matching command tag, but downstream behaviour is best-effort. Treat the table below as parser coverage; binder and executor support varies and must be validated against the workload.

When a statement is in the parser surface but a planner or executor path is missing, the engine returns the matching 0A000 (feature not supported) or 42704 (undefined object) SQLSTATE rather than silently succeeding.