QuestDB¶

Set DB_TYPE=questdb and provide QUESTDB_HOSTNAME. The default HTTP endpoint is port 9000.

DB_TYPE=questdb
QUESTDB_HOSTNAME=questdb.example.invalid
QUESTDB_PORT=9000
QUESTDB_MEASUREMENT_NAME=fritzbox
QUESTDB_DATA_RETENTION_DAYS=365
QUESTDB_TLS_ENABLED=true

Authentication¶

Use QUESTDB_USERNAME and QUESTDB_PASSWORD for basic authentication, or QUESTDB_TOKEN for bearer authentication. Do not configure both credential styles unless your QuestDB deployment requires it. TLS certificate verification remains enabled by default.

TTL¶

QUESTDB_DATA_RETENTION_DAYS is applied only when a table has no TTL. An existing TTL is never overwritten by a later application start. Set the value to 0 to disable automatic TTL setup. To change an existing TTL, use QuestDB administration directly, for example:

ALTER TABLE "fritzbox_<serial>" SET TTL 365 DAYS;

The <serial> placeholder is the sanitized FRITZ!Box serial; replace it with the actual table name. QuestDB TTL support must be available in the server version you run.

Downsampling¶

QUESTDB_DOWNSAMPLING accepts low, medium, or high. The profiles are:

Raw polling and ingestion are unchanged; QuestDB maintains the rollup through a materialized view and applies its TTL server-side. Requires QuestDB OSS 8.3.1 or newer.

Use the matching QuestDB dashboards from utils/grafana/questdb_dashboards/ after ingestion.

Choosing a profile¶

With QUESTDB_DATA_RETENTION_DAYS=365, one year of history costs roughly:

The two 1-minute profiles save far less than their raw window suggests: the rollup keeps five aggregates per gauge, so it costs about half a raw day per day rather than a fraction of one. Only high reduces the total substantially, and only because its 5-minute buckets cut the row count.

Logs, call logs, current snapshots and state histories are never downsampled. Their history ends with the raw window, so high leaves one day of log history regardless of the rollup retention.

Provisioning order¶

The active profile is published to the append-only status table only after the rollup exists, is reported valid and current, and the raw TTL has been applied and read back. Grafana routes on that status, so the raw_days it reads always matches the TTL QuestDB enforces. If the raw TTL cannot be established, no active status is published and the previous state remains in effect.

TTL ownership¶

A raw TTL that fritzfluxdb did not set is treated as administrator-owned and is never overwritten. The profile's raw window is then not applied, and the existing TTL is published as the effective raw history instead. A TTL that fritzfluxdb set itself is recorded as managed in the status table and is adjusted when the profile changes, which is what allows an existing installation to reduce its raw storage. On an upgrade from a version without ownership tracking, an existing TTL counts as administrator-owned.