DB
Get started
Back homeIndustry

SaaS & infrastructure

Ship analytics, materialized views, live queries and per-tenant access from one engine you run as one node process.

The problem

Where the usual stack breaks

  1. 01

    You reach for a database, then a cache, then a stream processor, then a separate auth layer for partner access, and end up operating four systems to ship one product feature.

  2. 02

    Each addition is more schema duplication, more consistency glue, and more surface to run in every environment from a developer laptop to production.

  3. 03

    One engine that covers keyed tables, analytical scans, continuous derivations, live queries and credentials behind one contract collapses the operational surface.

Where NYXDB fits

Use-case journeys

01

Product analytics & usage metrics

Raw product events become live metric tables, maintained by transformations.

Product & event analytics
02

Abuse & fraud prevention

Abuse checks read per-account totals that are current and events enriched at processing time.

Fraud & risk
03

Telemetry & infra monitoring

Columnar history of infra telemetry with keyed current state.

IoT & telemetry

Architecture

How NYXDB fits SaaS & infrastructure

One engine spans every table shape, transformations and materialized views, queries that stay open, users and API keys, and federation between instances through application access grants.

  1. 01

    Model

    Every row, the latest per key, or every version, with attribute groups, in one catalog.

  2. 02

    Derive

    Derived relations maintain themselves, as transformations and materialized views.

  3. 03

    Authenticate

    Credentials live in SQL, with CREATE USER and CREATE API KEY; passwords are bound parameters and key secrets are returned once.

  4. 04

    Share

    Expose exactly the rows that match a predicate to another instance, with an application access grant.

In practice

Representative statements

A user and an API key
CREATE USER analyst PASSWORD ?;
CREATE API KEY reporting FOR USER analyst EXPIRES IN 30 DAYS;
Read another instance’s balances through a source
-- on the instance that owns the tables
CREATE APPLICATION ACCESS analytics_reader;
GRANT read, subscribe
  ON TABLE balances
  WHERE chain_id = 1
  TO APPLICATION ACCESS analytics_reader;
ALTER APPLICATION ACCESS analytics_reader MINT SECRET;
-- on the reading instance
CREATE SOURCE ledger
  KIND nyxdb_instance
  OPTIONS (
    endpoint 'wss://ledger.example.com/client',
    credential 'analytics-reader'
  )
  EXPOSING (balances AS ledger_balances);

The examples use the same two tables on every page. See the SQL reference for full syntax.

Capabilities

What you get out of the box

One engine

Keyed tables, scans and streaming behind one contract.

Materialized views

Kept current by the engine; per-tenant instances from templates.

Users & API keys

SQL credential statements; secrets never appear in query history.

Federation

Read another instance’s tables through CREATE SOURCE, behind an APPLICATION ACCESS grant.

Learn more

Go deeper

Users & keys

CREATE USER and CREATE API KEY.

Federation

Sources and application access.

Deployment

Run the node.

Fewer systems, same capability

Explore the docs or run a node.

Get startedRead the docs