Read the source.
Query and routine language
The source syntax: types, tables, queries, references, relations, routines, policies, events, and specialized query forms.
Download language specification Original Markdown · 48 sections
Semantics and runtime behavior
What programs mean: values, conversions, constraints, atomicity, errors, authorization, concurrency, and committed visibility.
Download semantics specification Original Markdown · 50 sections
Theoretical storage engine
The architectural proposal: record identity, immutable versions, commit ordering, memory residency, storage layout, and reclamation.
Download storage specification Original Markdown · 66 sectionsDownloads are unchanged copies of the documents in the project's docs folder. The guides are curated explanations, not replacements.
Requirements and recommendations are different.
The syntax document defines source forms. The semantics document defines normative behavior: shall is a requirement, should is a recommendation, and may permits a choice. Their negative forms retain the same force.
The storage document explicitly describes a theoretical architecture and recommended structures. It is not a frozen on-disk compatibility contract. Internal details can change while preserving the language's meaning.
Read examples alongside the rules. A few original routine snippets use double-quoted error messages, while the source-form rules reserve double quotes for identifiers. The guides use single-quoted strings consistently and leave the original files intact.
A direction, not a release announcement.
This workspace contains specifications, not an engine implementation. The site does not offer a database binary, an executable playground, or performance benchmarks.
The initial engine proposal focuses on durable commits, transaction correctness, deterministic decisions, stable identity, row storage, and delta MVCC. Specialized search, columnar storage, replication transport, historical querying, and subscription dependency machinery are later architectural possibilities.
Scheduling delivery guarantees, exact storage thresholds, and several physical mechanisms remain implementation decisions. The semantics require protection from lost updates, not a blanket claim of strict serializability or exactly-once external effects.
The objective is to make the choices understandable before calling them finished.
From the specifications
This guide explains the design. The original documents carry the precise requirements and recommendations.
- sql_language_spec.md, section 1. Scope
- sql_semantics_spec.md, section 2. Normative Terms
- storage_engine_spec.md, section 1. Scope