Receive: investigate Zstd compression support for gRPC replication

Is your proposal related to a problem?

Thanos Receive currently supports snappy and none as compression options for gRPC communication between Receive instances.

For deployments with high-volume Receive replication traffic, network bandwidth can become a significant consideration. Zstd provides a configurable trade-off between compression ratio and CPU usage, which may provide better bandwidth efficiency for some workloads.

I would like to explore whether adding Zstd as an option for Receive gRPC replication would be beneficial.

Describe the solution you'd like

Add zstd as an additional option for --receive.grpc-compression, while keeping the existing snappy and none options.

For example:

--receive.grpc-compression=snappy
--receive.grpc-compression=zstd
--receive.grpc-compression=none

If this proposal is considered useful, I would like to contribute the implementation along with appropriate tests and benchmarks.

The benchmark would compare Snappy and Zstd in terms of:

• Compressed payload size / network bandwidth
• CPU usage
• Compression and decompression performance
• Throughput
• Latency

The goal would be to determine whether Zstd provides a meaningful benefit for Receive replication workloads rather than assuming it is always better than Snappy.

Describe alternatives you've considered

The existing Snappy compression is a reasonable option for low CPU overhead and fast compression/decompression, so continuing to use Snappy is one alternative.

Another option would be to rely on compression at a lower network or infrastructure layer. However, application-level compression allows Thanos to explicitly control the trade-off between CPU usage and network bandwidth.

I would prefer adding Zstd as an optional compression method rather than replacing Snappy, so existing deployments would remain unchanged.

Additional context

This proposal is specifically about gRPC communication between Thanos Receive instances.

It is separate from compression used for storing data in TSDB blocks or Parquet files.

I have not started implementing this yet. I would like to get feedback from the maintainers on whether this is a useful direction before working on the implementation.

If the proposal is accepted, I would be happy to prepare a PR with the implementation, tests, documentation, and benchmark results.