Benchmark-first
Upgrades do not cost you latency: a regression on a hot path blocks the release, and every hot path ships with a benchmark case and a measured before and after, not an estimate.
Company
A database for systems that must not be wrong.
You read fresh state, full history and live answers from one SQL database, and every derived table and live query is kept exact from each committed write. NYXDB is developed for the products that run on it.
How we work
Three rules you can hold us to
“The goal is not to glue several systems together behind one API — it is to make streaming, querying, and durability behave like one system.”
01 02 One publication contract
Nothing you derive drifts from its source: transformations, materialized views, indexes and streaming queries all follow the same publication of committed writes, never a private copy.
03 Correctness is the product
The number you read is the number the definition gives: derived tables are maintained exactly, never approximated.
How we build
Built in the open, shipped on evidence
Four habits behind every release.
- 01
Developed in the open
Engine development happens in public on GitHub. You can follow the work as it lands, read the issues and open your own.
GitHub
- 02
Measured before it ships
Every hot path carries a benchmark case with a measured before and after. A latency regression fails the gate instead of reaching you.
benchmark gate
- 03
Stored formats only grow
A newer build opens the data directory of an earlier one. Stored formats are added, never rewritten in place, and a new format is activated explicitly in the node configuration.
additive formats
- 04
One publication contract
Every derived table, materialized view, index and live query follows the same publication of committed writes, so nothing you derive drifts from its source.
PSI
What one engine replaces
The cache, the queue and the glue, retired
- Reads that trail their writes
- When a value reaches you a hop after it was written, it is stale exactly when you need it most. One engine serves the table itself, so the next read after a write already sees it.
- Systems that must agree
- Every extra system is another copy to keep in step, another serialization on every hop and another way for two stores to disagree. One engine is the single source, and everything derived from it reads the same publication.
- Several writers, one row
- When several pipelines update parts of the same entity, the last one wins and the rest are lost. Attribute groups give each writer its own columns and its own version order, so nothing is overwritten.
two writers, one versioned row
CREATE TABLE balances ( chain_id UINT16 NOT NULL, address STRING NOT NULL, token STRING NOT NULL, amount UINT256 NULL, updated_at DATETIME64(3, 'UTC') NULL, balance_index UINT128 NULL, balance_version UINT64 NULL, transfer_count UINT64 NULL, last_transfer_at DATETIME64(3, 'UTC') NULL, activity_index UINT128 NULL, PRIMARY KEY (chain_id, address, token), ATTRIBUTE GROUP holding (amount, updated_at, balance_index, balance_version) VALID BY (balance_index) REVISION BY (balance_version), ATTRIBUTE GROUP activity (transfer_count, last_transfer_at, activity_index) VALID BY (activity_index))MODE VERSIONEDSHARD BY (address) SHARDS AUTOORDER BY (chain_id, address, token)STORAGE PROFILE ROW;Work with us
Tell us what you are building
Three ways to reach the people who build the engine.
Design partners
Put the engine into production with us
Teams taking NYXDB into production work directly with the engineers who build it: your schema, your derived tables, your deployment. Write to us with what you are building.
Email
Commercial support and partnerships
Commercial support, partnerships, and anything that does not belong in a public issue.
GitHub
Follow the engine as it is built
Development happens in the open. Read the issues, follow the work as it lands, and open an issue of your own.
Get in touch
Start with the documentation, or follow engine development in the open on GitHub.