Data retention
Retention defaults, the safety-net TTL, and storage management knobs in self-hosted Radicas.
Self-hosted organizations have no subscription, so the per-plan retention ladder does not apply: by default your data is kept forever — Radicas never deletes an operator's telemetry on an unconfigured default.
Two mechanisms still bound growth, both under your control:
1. The safety-net TTL
The backend owns the raw ClickHouse tables (otel_traces, otel_logs) and creates them
with a table-level TTL of RETENTION_MAX_DAYS (default 365). The collector must run
with create_schema: false (the shipped config does); boot the backend once before sending
telemetry so the tables exist. Changing RETENTION_MAX_DAYS reconciles the TTL at the next
backend start.
2. Per-organization retention
To enable time-based deletion for a tenant, set a retention override from the admin panel
(entitlements → retention override, in days). The daily sweep (RETENTION_CHECK_SECONDS,
default 86400) then deletes older data with tenant-scoped lightweight deletes, ledgered in
data_deletion_request.
| Env | Default | Meaning |
|---|---|---|
RETENTION_MAX_DAYS | 365 | Safety-net TTL on the raw tables |
RETENTION_DAYS_DEFAULT | 90 | Fallback for subscribed tenants only — inert in self-host |
RETENTION_CHECK_SECONDS | 86400 | Sweep cadence |
STORAGE_STATS_SECONDS | 3600 | Storage-stats materialisation cadence |
OWN_RAW_SCHEMA | true | Backend applies the raw DDL at startup |
Storage visibility and deletion
The Usage page's Storage section (rows, estimated bytes, oldest/newest) and the manual
range/full deletion work identically to the SaaS product. The backend's ClickHouse user
needs SELECT plus ALTER DELETE on the otel database for the sweep and manual deletes.
Bronze bucket
If you enable the S3/bronze exporter, add a lifecycle expiration rule on the bucket
(the SaaS profile uses 365 days on the otlp/ prefix). The layout is time-partitioned, so
expiry is bucket-wide, not per-tenant.