[compact] Add Tenant-based config overrides

[ricket-son]

Is your proposal related to a problem?

In a multi-tenant setup, all tenants currently share the same compactor configuration (e.g., retention period, downsampling behavior, block size, etc.).
This becomes a limitation when different tenants have distinct data retention or compliance requirements.

For example, tenant-a might want to retain metrics for the default duration (e.g., 90d), while tenant-b should only retain metrics for 5d, to save on storage or comply with short-term monitoring policies.

Currently, there is no straightforward way to configure retention or compaction parameters on a per-tenant basis.

Describe the solution you'd like

Introduce tenant-based configuration overrides for the Compactor (and potentially other Thanos components like store gateway or receive in the future).

Specifically, for thanos compact, allow defining tenant-specific overrides such as:

• Retention duration (--retention.resolution-*)
• Downsampling configuration
• Compaction concurrency or scheduling

The configuration could be provided via a structured file (yaml/json) or dynamically through a sidecar config reload mechanism, e.g.:

tenants:
  tenant-a:
    retentionResolutionRaw: 90d
    retentionResolution5m: 180d
  tenant-b:
    retentionResolutionRaw: 5d

This would allow operators to fine-tune data retention and storage efficiency per tenant without spinning up separate compactors.

Describe alternatives you've considered

• Running multiple compactors, each targeting specific tenant prefixes.
  • This is cumbersome and adds operational complexity.
• Using object storage lifecycle policies directly.
  • This is storage-provider-specific and doesn’t integrate with Thanos’ compaction logic.

Both approaches work but lack the flexibility and simplicity of native configuration overrides.

Additional context

This feature would be especially useful in multi-tenant Thanos deployments.
It would allow finer-grained control of metric retention and compaction behavior, improving both cost efficiency and compliance handling.

[GiedriusS]

Maybe this could be first introduced as a RFC? We could hash out the parameter names, etc. inside of there because this can be applicable not just to the Compactor but also to other components.

[ricket-son]

That's exactly what I was thinking about. Thought to just start with compactor as a pilot.
But I guess it would make more sense to declare it in general, so there is a standardised configuration beyond all components.