feature: remote write

[george-vieira]

I see push gateway is supported but I was hoping to have a remote write support as it uses snappy compression

[unlikelyzero]

It's worth noting that this feature has moved out of alpha and as of 2.33 is a regular feature

[SimenB]

PR welcome? 😀

[unlikelyzero]

prometheus/prometheus#10119

[umutuzgur]

We actually implemented this at Checkly. The problem is that you gotta create a intervalled scraper to use remote_write correctly to avoid the timestamp out of order errors. I can send a PR for this but I don't know if it would match the expectations/code quality of the repo 😅

[humdrum00001010]

Still relevant in 2026, so adding one data point rather than a bare +1.

Use case: a small NestJS API on a 1 GB ARM instance with very little free RAM, shipping metrics to Grafana Cloud. prom-client already had everything we needed on the instrumentation side — the only gap was the wire protocol to get it off the box. That left running a sidecar agent purely as a protocol translator, which on a box that size is a meaningful fraction of the memory budget.

I think @umutuzgur's comment above is the crux and is worth restating, because it reframes the ask:

you gotta create a intervalled scraper to use remote_write correctly to avoid the timestamp out of order errors

The missing piece isn't really snappy + protobuf — it's the periodic collection loop. remote_write requires monotonically increasing timestamps per series, so a correct implementation has to own an interval timer and drain the registry on a schedule, rather than serialize on demand the way register.metrics() does today. That's an architectural addition, not just an exporter function, which is probably a fair part of why this has sat for four years.

For anyone finding this issue later: the practical workaround is the OpenTelemetry JS SDK, whose PeriodicExportingMetricReader is precisely that loop. It does mean leaving prom-client, and OTel's HTTP instrumentation has slightly different semantics (http.server.request.duration, and it omits http.route on unmatched requests rather than falling back to a raw URL — which is a nice cardinality property, incidentally).

Not asking anyone to prioritize this — just noting the demand hasn't gone away, and that the real work is likely the collection loop rather than the encoding.