Storage settings
Every setting below is read once at startup and requires a restart to change.
Built-in defaults are overridden by nonempty environment values.
Unknown FANOUT_ names fail startup; platform-injected service names are tolerated.
Vendor credentials and endpoints keep the vendor’s documented names.
| Environment variable | Type | Default |
|---|---|---|
FANOUT_DATA_DIR | string | ./data |
FANOUT_DUCKDB_MAX_CONNECTIONS | integer | 0 |
FANOUT_DUCKDB_MEMORY | string | — |
FANOUT_DUCKDB_THREADS | integer | 0 |
FANOUT_MAINTENANCE_INTERVAL | duration | 1h |
FANOUT_RETENTION_DAYS | integer | 30 |
FANOUT_ROLLUP_INTERVAL | duration | 1m |
FANOUT_ROLLUP_SKIP_TO_LATEST | boolean | false |
FANOUT_DATA_DIR
Section titled “FANOUT_DATA_DIR”Stores telemetry, query state, and the control database.
FANOUT_DUCKDB_MAX_CONNECTIONS
Section titled “FANOUT_DUCKDB_MAX_CONNECTIONS”Caps the DuckDB read connection pool. Reads scan immutable Parquet concurrently; analytical and completed-batch writes use separate gates and connections. Zero selects available Go CPUs, bounded to 2–16. Startup logs and /readyz report the resolved pool size.
FANOUT_DUCKDB_MEMORY
Section titled “FANOUT_DUCKDB_MEMORY”Caps DuckDB’s memory (e.g. “8GB”). Empty selects 60% of detected available memory, reserving headroom for Go. If detection fails, DuckDB uses its default with a process headroom adjustment. Startup logs and /readyz report the resolved budget and detection status. Set an explicit cap when memory limit detection is incomplete.
FANOUT_DUCKDB_THREADS
Section titled “FANOUT_DUCKDB_THREADS”Caps DuckDB’s global query worker pool. Zero leaves DuckDB’s own default in place (one worker per core). Set it to leave cores free for ingest on a query-heavy co-tenant host.
FANOUT_MAINTENANCE_INTERVAL
Section titled “FANOUT_MAINTENANCE_INTERVAL”Controls Parquet retention and compaction, and query-cache checkpointing.
FANOUT_RETENTION_DAYS
Section titled “FANOUT_RETENTION_DAYS”Sets telemetry retention in days; zero disables expiry.
FANOUT_ROLLUP_INTERVAL
Section titled “FANOUT_ROLLUP_INTERVAL”Schedules analytical rollups; use a Go duration of at least 1s.
FANOUT_ROLLUP_SKIP_TO_LATEST
Section titled “FANOUT_ROLLUP_SKIP_TO_LATEST”Set once at boot, this advances the service and edge rollup watermarks to the current max ingested timestamp. Existing history is not aggregated into those analytical rollups. Completed-batch trace caches still rebuild all retained history in bounded passes; uncached files remain immediately queryable. Useful for large pre-seeded datasets (benchmarks, restores); off in normal operation.