The questions a technical buyer asks first
Straight answers about what the engine is, how you run it, how it protects your data and how you buy it. Every answer restates the docs or a page on this site; anything else is answered in the open on GitHub.
What the engine is
What NYXDB is, what a table keeps, and how derived tables, live queries and point-in-time reads work.
A SQL database. Your tables hold exact current and versioned state, and the derived tables, materialized views and streaming queries you define are kept current from every committed write, inside the engine. There is no separate stream processor to run.
Running it
Where the engine runs, how a node is installed and reached, and what upgrades, backups and recovery look like.
On your infrastructure. NYXDB is self-hosted software: one process started with a configuration file and a data directory, inside your own environment. There is no NYXDB-operated cloud that your production data flows through, and your existing network, encryption and access controls apply directly.
Security and trust
How credentials, sessions and grants work inside the engine, what leaves a trace, and how to report a problem.
Never in your query text. A password travels as a bound parameter and is stored as an Argon2id verifier. An API key’s secret is returned once, when it is created, and never shown again. Credential statements reach query history only in redacted form. See Authentication.
Buying it
How pricing works, how to try the engine first, what support looks like, and how to reach the team.
Per deployment, after one conversation. You tell us what you run: the tables you keep, the write volume they take, the nodes you plan and the support you want, and we price that deployment. There is one engine, so every quote covers all of it, and there is no published price list.
Everything else is one question away
Ask in the open on GitHub, or write to the team that builds the engine. Either way, the answer ends up where the next person can find it.