Operations
Deployment topologies
How a NYXDB deployment is laid out — node processes, tablets and replicas, and the checks to run before going live.
A node
A NYXDB node is one process. It serves the HTTP and WebSocket gateway, SQL, the tablets that hold table data, PSI, and every derived consumer: indexes, transformations, materialized views and streams. A write is acknowledged once the node's write-ahead log holds it.
Tables across nodes
A table is split into shards by its SHARD BY key. Each shard is a tablet
with its own write-ahead log domain. Tablets are replicated across nodes, and
a replica takes over when a node is lost; tablets move, split and merge as the
data grows.
| Layer | What it does |
|---|---|
| Gateway | Authenticates sessions and routes each statement. |
| Tablets | Own the rows of one shard, their history and their indexes. |
| PSI | Publishes every committed change once to every subscriber. |
| Derived consumers | Keep transformations, views and streams current. |
Pre-deployment checks
GET /auth/issuerslists thepasswordandapi_keyissuers once the issuer key is configured.- Read
system.settingson a WebSocket session to confirm the effective node values of the registered settings and their origin. - Confirm that a user without a role is denied a read (403) and that the same
read succeeds after a role grants
relation_read. - For federation, confirm
system.sourcesreports each sourceready.