Documentation
Introduction
NYXDB is a SQL database that keeps exact current and versioned state and maintains derived results from every committed write.
NYXDB is a SQL database whose tables keep exact current and versioned state, and whose transformations, materialized views and streaming queries are maintained continuously from every committed write.
Choose your path
Get startedWhat the getting-started guide covers and your first queries.CapabilitiesEverything NYXDB provides, in one place.ConceptsTables, attribute groups, versioned state, transformations, PSI and streaming reads.SQL referenceEvery statement, with examples over the same two tables.FunctionsThe function reference, generated from the function catalog.Drivers and integrationsHTTP routes, the WebSocket session, the clients and the tools that reach a node.OperationsDeployment, system relations, governance and the operator pages.GuidesEnd-to-end guides: live dashboards, feature stores, audits over history and migrations.
What NYXDB provides
- Three table modes.
MODE APPENDkeeps every row,MODE UPSERTkeeps the latest row per primary key, andMODE VERSIONEDkeeps the latest row plus every accepted version. See Tables. - Attribute groups. One keyed row can be split into independently written column groups, each with its own ordering. See Attribute groups.
- Declared ordering and point-in-time reads.
VALID BYandREVISION BYchoose the current winner per key, andAS OF COMMITreads a past commit. See Versioned tables. - Transformations and materialized views.
CREATE TRANSFORMATIONwrites a continuously maintained result into an existing table; materialized views keep an engine-owned result. See Transformations. - Streaming reads.
STREAM SELECTreturns one snapshot and then exact changes over a WebSocket session. See Streaming reads. - Transactions and replication.
BEGIN…COMMITgroups statements atomically, and tablets are replicated across nodes with automatic failover. See Transactions. - Users, API keys and federation. Password and API-key logins issue short-lived bearers, and one instance can read another's tables as external relations. See Authentication and Federation.