GitHub
Community support
Get an answer in public, where the next person can find it: questions, bug reports and feature requests are handled in the open on GitHub. Search existing issues first, then open a new one with a reproducible example.
Support & Releases
Get help, and upgrade without surprises.
NYXDB is developed in the open: ask on GitHub, or reach us by email for commercial support. Releases are versioned and benchmark-gated, so an upgrade holds no surprises for you.
Channels
Two ways to get an answer
Docs
Documentation
Every statement you read in the docs is backed by the engine test that runs it. Concepts, the SQL reference, the protocol and operations are all covered.
Releases
Upgrade on your schedule, not ours
Every build you run is pinned to a commit, gated on performance, and changes stored formats only by adding to them.
- 01
Commit-pinned builds
You decide when a deployment changes: every build is identified by the engine commit it was made from, so you can pin a known-good build and move off it deliberately.
- 02
Benchmark-gated
An upgrade does not hand you a slower system: hot paths ship with a benchmark case and a measured before and after, and a latency regression fails the gate instead of shipping.
- 03
Additive formats
Your data on disk is never rewritten under you: stored formats are added, never rewritten in place, and a new format is activated explicitly in the node configuration.
Operations
The runbook, written down
Deploying, configuring, diagnosing and upgrading a node, each on its own page with the relation or configuration key to read.
- Deployment01
Several nodes, one process each
Each node runs with its own data directory and configuration file. Tablets are replicated across the nodes, and a replica takes over when a node is lost.
- Configuration02
One file, read at start
Keys grouped by area: the issuer key, request deadlines, stream lifetimes, the drain time and the recovery workers. Every value in force is visible with its origin.
- Troubleshooting03
Symptom first, relation second
Slow writes, a growing log, a lagging derived table, a stream falling behind, a long query: each symptom is paired with the system relation that explains it.
- Upgrade compatibility04
A newer build opens the same directory
Tables, versions, definitions and checkpoints carry over to a newer build. Upgrade one node at a time while the replicas keep serving.
- Backup and recovery05
A consistent copy, restored at its commit
A backup captures a node’s tables, their versions and the definitions that maintain them. A restore brings them back at the backup’s commit, and transformations resume from their checkpoints.
- Limits06
Every limit names its key
Deadlines and limits derive from the node’s hardware, an explicit configuration key wins, and a limit that is reached names itself and the key that sets it.
Operations FAQ
Questions before you go live
Short answers from the operations docs. Anything else, ask in the open on GitHub.
By the engine commit it was built from. Every build carries that commit, so you can pin a known-good build, name it in an issue, and move off it deliberately.
Reporting an issue
Three steps to a report we can act on
Issues live in the open on GitHub. The more of this your report carries, the sooner it turns into a fix.
01 Search before you open
Search the existing issues first: your symptom may already have a thread, a fix in flight or an answer, and the next person then finds it where you did.
GitHub issues
02 Reduce it to one statement
Cut the case down to a reproducible statement over the two canonical tables, balances and transfers, the same two every example in the docs runs on, so the case can be replayed as written.
balances · transfers
03 Name the build and what you expected
State the engine commit your build was made from, the statement you ran and the result you expected. Every build is identified by its commit, so the report lands on exact code.
engine commit