Connect a database

ClickHouse is where every table a frame reads lives — your telemetry and Noemata’s own file store. It’s the only supported database today (Apache Doris and DuckDB/SQLite are planned). You configure it under db.clickhouse in noemata.json, and the setup wizard writes that block for you the first time you run noemata config or noemata init.

There are two shapes, and you pick exactly one.

Managed local binary

The default. Noemata downloads a ClickHouse binary and runs it for you — nothing to install, nothing to keep alive. noemata up starts it alongside the rest of the stack.

{ "db": { "clickhouse": { "binary": {} } } }

Every field is optional:

• version — pin a ClickHouse release instead of the bundled default.
• http_port / native_port — a number, or "auto" (the default). "auto" binds 8123 / 9000 plus the worktree offset, so parallel worktrees don’t collide.
• max_memory_gb — cap ClickHouse’s memory.
• data_dir — where it stores data on disk.

External server or ClickHouse Cloud

Point Noemata at a ClickHouse you already run — a server on your network or ClickHouse Cloud. up won’t try to start or manage it; it only connects.

{
  "db": {
    "clickhouse": {
      "external": { "hosts": "my-clickhouse.example.com", "http_port": 8443 }
    }
  }
}

• hosts — the ClickHouse host to connect to.
• http_port / native_port — override the ports it listens on.

Shared settings

These apply to both shapes:

• authentication — "none" (the default) leaves ClickHouse open and the app connects anonymously; "password" applies the ClickHouse default user’s password, and the Noemata UI requires a login.
• default_database — the database the app binds to and the collector exports into. Defaults to "default".
• namespace — the table prefix for Noemata-owned tables like the file store. Defaults to "noemata".
• request_timeout — how long a dashboard query may run, in seconds (defaults to 60). One knob that bounds both layers: the browser aborts the request after this, and it seeds the server-side max_execution_time backstop so ClickHouse stops working even if the client’s cancellation doesn’t land.
• query_settings — a passthrough map of ClickHouse settings sent with every dashboard query (e.g. { "max_threads": 2 }). These layer over request_timeout’s derived max_execution_time — so setting max_execution_time here overrides just the server-side cap while leaving the client timeout at request_timeout. Noemata otherwise leaves ClickHouse’s performance knobs at the server’s own defaults; this is the escape hatch for expert tuning.

There are no separate user, password, or TLS fields under db — authentication is the whole credential surface. (TLS on the Noemata UI itself is configured elsewhere, in the setup wizard.)

What ends up in the database

Two kinds of tables share the database. The collector writes telemetry into otel_traces, otel_logs, and the metrics tables (see Send telemetry). Noemata writes its own state — the file store and related tables — under the namespace prefix. Frames query the telemetry tables through the semantic-layer views the integrations install, so a frame refers to DurationP95, not a raw column.

The full db schema, including every field above, is in the project config reference.