Architecture
A query enters as SQL, becomes a plan, is checked by the verifier on the data node, and runs against the storage engine. Each layer has one job and a narrow interface to the next.
Layers
| Layer | Job | State |
|---|---|---|
| Gateway (Go) | PostgreSQL protocol, token authentication, SQL parsing and binding into a plan. | First SQL subset built |
| Planner | Rewrites plans for speed, inserts the security operators. | Built (rule-based) |
| Verifier | Checks types and security on the data node before anything runs. | Built |
| Executor | Runs plans on columnar batches; the reference interpreter defines the correct answer. | Built: vectorized executor and reference interpreter |
| Storage engine (Rust) | Durable, versioned keys and values with transactions. | Built |
| Control plane (Go) | Placement, replication, membership, upgrades. | Planned |
Language split
The storage engine, plan layer, verifier and executor are written in Rust. The gateway is written in Go, and so will be the control plane, migration tools and SDKs. The engine crates have no third-party dependencies (token verification in the node server uses the RustCrypto RSA and SHA-2 crates) and forbid unsafe code; the hash, checksum and encoding code is written and tested in the project itself.
Why the verifier sits on the data node
The gateway and the optimizer are large and change often. The verifier is small and changes rarely. Checking every plan where the data lives means that a bug in the optimizer, a stale cache entry or a hand-written internal plan cannot read another tenant's data: the node refuses the plan. See Security model.
Resource discipline
The engine reads its memory limit from the operating system (cgroup) and divides it between the write buffer, the block cache and queries. When memory runs short it shrinks the cache first, then flushes, then turns writers away with a clear "overloaded" error rather than slowing down without warning.