Architecture

A NYXDB node is one process. Everything a client reaches — sessions, SQL, storage and derived results — runs inside it, and nodes replicate tablets to one another.

clientsHTTP, WebSocket

gatewayHTTP routes, WebSocket sessions, authentication

SQLparse, bind, plan, execute

writes

reads

tabletsone owner per tablet, a WAL domain, immutable parts

every committed batch

PSIthe committed-change feed

transformationsmaterialized viewsindexesstreaming reads

Gateway

The gateway accepts HTTP requests and WebSocket sessions. HTTP carries session exchange, one-shot SQL and the bulk write routes. A WebSocket session on GET /client multiplexes many requests, including streaming reads, by request id. Every request runs under an authenticated session; see Authentication and Protocol.

SQL

One statement per request, at most 64 KiB. The engine parses, binds against the catalog, plans and executes it. Credential statements and federation statements are classified before the relational parser and never reach it.

Tablets

A table is split into tablets by its SHARD BY clause; the shard count is fixed when the table is created. Each tablet has one owner that serializes its commits, identified by an owner epoch and a commit sequence. Records go to a local, segmented, checksummed write-ahead log (WAL) with group commit, and a write is acknowledged only after it is durable. Each runtime has a set of WAL domains, and each tablet maps to one of them. Committed data is kept in immutable parts. See Storage.

PSI

Every committed tablet batch is published once on that tablet's committed feed. Subscribers select changes by relation, component and key, keep their own durable cursor and acknowledge only what they applied; the tablet never waits for them. See PSI.

Derived consumers

Transformations, materialized views, indexes and streaming reads are PSI subscribers. A transformation writes into an ordinary table, so its output is again published on PSI and can feed the next transformation. See Transformations and Streaming reads.

Control plane and replication

A Raft quorum runs the control plane. Each tablet is replicated across nodes; when a node is lost, a replica takes over. Tablets migrate, split and merge at run time as the data grows.