Summary: On October 12, 2026, Cloudflare shipped Transformers, a SQL-based transformation layer that runs inside the Logpush export pipeline. Instead of maintaining a separate processing service to drop health checks, redact IPs, or reshape records, you attach a query to your Logpush job and only the transformed output reaches your SIEM or storage. It’s available on Free through Enterprise plans, which makes log hygiene something you can do by default rather than as a paid side project.
The problem: paying for logs you throw away
If you run Logpush today, you already know the pattern. The job streams everything — internal health checks, fields your compliance team doesn’t want leaving the edge, records in a shape your analytics platform can’t use. So teams bolt on a processing service: deploy it, scale it, monitor it, pay for it.
The cost is quieter but real too. As Cloudflare’s post points out, teams pay to export, ingest, and store records they discard as soon as they arrive. Filtering at the export boundary shrinks every downstream bill at once. (I touched on a related angle — where Cloudflare hides observability signals — in an earlier post on challenge pages as a latency data source.)
How a Transformer works
A Transformer is a SQL query scoped to one Logpush dataset. Logpush applies it per batch before export: rows failing the WHERE clause are dropped, and the SELECT output becomes the exported record in NDJSON. You can rename or nest fields, add static values (say, a provider column when normalizing logs from multiple CDNs), and redact substrings like part of a client IP.
A minimal example of the shape:
SELECT
ClientIP AS client_ip,
边缘Trace AS trace,
'cloudflare' AS provider
FROM http_requests
WHERE ClientRequestPath NOT LIKE '/health%'You build and preview queries in Transformer Studio in the dashboard, or manage them via API. Each save creates a new version, so you can see how a transformation evolved — a small touch, but it matters when a redaction rule changes and someone asks what shipped last quarter.
The engineering choice worth stealing
The part I found most instructive is what Cloudflare rejected. Their first prototype ran customer WebAssembly Transformers in Workers, but that would have put a network hop into the export hot path — a remote dependency that could time out and retry. They chose in-process execution instead, embedding Apache DataFusion (a Rust SQL engine on Arrow) directly inside Bufstream, their Go-based delivery service handling over 110 million records per second.
Crossing the Go/Rust boundary uses Arrow IPC over a C ABI via cgo, with explicit buffer ownership: Rust hands back the output, Go copies it, then releases the Rust allocation. Their benchmark on a synthetic 5,000-row batch took about 3 ms per transform — roughly 1.6 million rows per second from a single goroutine.
The takeaway for builders: putting a transformation engine inside the delivery path beats bolting it on as another service, especially when the transformation is a guarantee (redaction, schema) rather than an enrichment.
Failure behavior is the feature
Transformers fail closed. If a transform can’t execute, Bufstream doesn’t advance the job offset and doesn’t send raw data — delivering untransformed logs could break the exact schema and redaction assumptions you configured. Retries back off progressively, persistently failing jobs get disabled automatically, and the Transformer Health view shows success rates, pre- and post-transform volume, and duration.
If you’re evaluating it, the practical next step is small: pick one Logpush job, write a query that filters health checks and redacts client IPs, preview it in Transformer Studio, and compare the before/after data volume in the Health tab. That delta is your actual savings case — the supplied documentation points to the Logpush pricing docs for what it translates to in dollars.
Sources
View the original post on X