NYXDB is priced per deployment, after one conversation about your workload: the tables you keep, the write volume they take, the nodes you run and the support you want. The engine is self-hosted, so you can run a node on your own infrastructure before that conversation starts.
A page cannot size your deployment and a form cannot ask a follow-up question, so pricing starts with an email. Write to the team that builds the engine with the four points beside this, and the conversation starts from your workload.
[email protected] · subject: NYXDB pricing
What the tables hold, what you derive from them, and what reads them live: a dashboard, a service, another instance.
How many rows land per second at peak, how many tables take them, and how much history you keep.
Your own cloud account or your own machines, in one region or several, and how many nodes you plan.
Community support in the open on GitHub, or commercial support by email with the team that builds the engine.
How pricing works
Pricing is set per deployment, in one conversation about what you run. You can run a node on your own infrastructure before that conversation starts.
NYXDB is self-hosted software: one process started with a configuration file and a data directory, inside your own environment. Your network, encryption and access controls apply directly, and your data has one home, yours.
One conversation sets the price: the tables you keep, the write volume they take, the nodes you run and the support you want. You get a quote for that deployment, with everything in the engine included.
Community support happens in the open on GitHub, where the next person can find the answer. Commercial support is by email, with the team that builds the engine, and is part of the same conversation.
Two ways to run NYXDB
Every deployment runs all of the engine on your infrastructure. The two columns differ in one place: who you ask when you have a question.
| Concern | Run it yourself | With commercial support |
|---|---|---|
| Where it runs | IncludedYour infrastructure: your cloud account or your own machines. | IncludedYour infrastructure: your cloud account or your own machines. |
| What you get | IncludedEverything in the engine. | IncludedEverything in the engine. |
| Upgrades | IncludedCommit-pinned, benchmark-gated builds, on your schedule. | IncludedCommit-pinned, benchmark-gated builds, on your schedule. |
| Your data on disk | IncludedStored formats are added, never rewritten in place. | IncludedStored formats are added, never rewritten in place. |
| How you start | IncludedInstall a node from the docs and run your first queries. | IncludedOne conversation about your deployment, then a quote for it. |
| Who answers | IncludedThe community, in the open on GitHub. | IncludedThe team that builds the engine, by email. |
Most rows match on purpose. Commercial support changes who answers, not what ships.
Talk to usWhat’s included
There is one engine, and every deployment runs all of it. Each row below is a capability the docs describe, grouped by the page that describes it.
| Capability | Every deployment |
|---|---|
| Append, upsert and versioned tables | Included |
| Attribute groups, one writer each | Included |
| Row, columnar and hybrid storage profiles | Included |
| Shards and partitions | Included |
| MINMAX, BLOOM and POSTINGS indexes | Included |
| Column encodings and codecs | Included |
| Capability | Every deployment |
|---|---|
| Transformations into a table or one attribute group | Included |
| Materialized views and logical views | Included |
| Lookup and as-of joins | Included |
| Grouped aggregates | Included |
| Exact derived state, kept across restarts | Included |
| Capability | Every deployment |
|---|---|
| STREAM SELECT: one snapshot, then exact changes | Included |
| Tumbling, hopping and session windows | Included |
| EMIT controls for when results are released | Included |
| Multiplexed WebSocket sessions with demand-based delivery | Included |
| Streams over system relations | Included |
| Capability | Every deployment |
|---|---|
| Every accepted version, retained | Included |
| VALID BY and REVISION BY version order | Included |
| AS OF COMMIT reads | Included |
| Write receipts and read-after-write | Included |
| Transactions across rows and tables | Included |
| Capability | Every deployment |
|---|---|
| Users and API keys, managed in SQL | Included |
| Sessions from short-lived signed bearers | Included |
| Roles and data grants, deny by default | Included |
| Application access grants with row predicates | Included |
| Federation between instances | Included |
Pricing questions
The practical questions a technical buyer asks first. Anything else, ask us directly, or in the open on GitHub.
Send your use case, the write volume you expect and where it runs, and the conversation starts from there.
Per deployment. 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.
Write to us with your use case, the write volume you expect and where it runs. Your email reaches the team that builds the engine.
Self-hosted · your infrastructure · one conversation