Armin Ronacher Revives Deser, a Serde Rival That Reads JSON 10% Slower

Armin Ronacher published a post on 29 September 2026 arguing that Rust's Serde library has design limits that "cannot be fixed without breaking every format", and released Deser, an experimental library built on a different architecture. On his own benchmarks, Deser reads JSON about 10% slower than serde_json on average.

The post, titled Deser: Rethinking Rust Serialization, says the project began in 2022, was abandoned for years and has now "reached a point where I think it's worth looking at." The repository showed 326 stars, 7 forks and no open issues on 30 September. The code is Apache-2.0. The post itself is under a Creative Commons non-commercial licence.

Why Sentry's JSON pipeline drove it

Ronacher traces the design to Sentry Relay, which processes what he calls "enormous amounts of untrusted JSON." Untrusted input is the reason the stack matters. Serde deserialises by recursion, so every level of nesting adds a stack frame. A hostile payload nested deeply enough can exhaust the stack.

Deser flips the control flow. In Ronacher's words, "the format tells the type of the next value and pushes events into a sink." State lives on the heap in an arena, so nesting depth no longer consumes the call stack. It also means a parser can be suspended and resumed, which is what streaming and async parsing need.

The three Serde problems he lists

The post names three concrete failures, each of which he says comes from Serde's visitor design rather than from a bug.

First, with the arbitrary_precision feature of serde_json switched on, internally tagged enums fail, because the buffer cannot recognise the magic keys used to carry big numbers. Second, flattened structs lose type information while buffering, so a JSON string key stays a string instead of becoming an integer. Third, a custom deserialize_with function does not compose through wrappers such as Option or Vec, so each combination needs its own adapter.

The README adds a fourth claim: that buffering in Deser "does not lose information", which is the property the first two failures lack.

What the benchmarks say

The figures below are the author's own, run on his own code, and no independent party has reproduced them.

Operation	Best case vs serde_json	Worst case	Average
JSON reading	33% faster	60% slower	about 10% slower
JSON writing	3x as fast	70% slower	a wash

Ronacher reports that YAML and TOML parsing is "noticeably faster than the Serde based crates". He says compile times are "slightly" better, "but not dramatically so". That is a narrow trade for anyone whose hot path is JSON: a spread from 33% faster to 60% slower means the average hides the payloads that matter.

What it will not do

Deser handles self-describing formats only. Protobuf is "quite intentionally left out of the design entirely", and the README lists bincode and postcard as excluded. It covers JSON and its variants (JSONC, JSON5, HJSON), CBOR, MessagePack, YAML 1.1 and 1.2, TOML, XML, plist, CSV, URL-encoded data and environment variables.

The README says a deser-serde crate bridges the two ecosystems, and the repository describes the whole project as experimental. The post does not say how much of an existing Serde codebase the bridge covers.

This is the same pattern as Hindsight's benchmark score, which its own authors published: a credible builder, a repository with stars, and numbers nobody else has yet run. Another developer-tooling release covered here is Cloudflare's cf CLI.

The README points to a LIMITATIONS.md file for constraints the post does not cover. It is the next thing to read before trying Deser on a real payload.