Most developers treat JSON querying as free. It isn't, and two recent articles make the case from opposite directions. One used a regular language and an optimal traversal mechanism - the other used AI to rewrite data access and transformation in Go to remove RPC calls.
\nMicah Kepe's jsongrep attacks the problem at the algorithm level. The core insight: a JSON path query is a regular language - it describes paths through a tree using a grammar with no ambiguity, no recursive lookahead, no edge cases that blow up on unusual input.
\nThat matters because regular languages can be compiled into a deterministic finite automaton. A DFA processes input with O(1) work per symbol -no backtracking, no interpretation at runtime, and crucially, no surprises. Tools like jq and jmespath interpret path expressions as they traverse the document; jsongrep compiles the query first, then walks the document exactly once, pruning entire subtrees in O(1) when the DFA says they can't match.
The formal constraint is also a feature: by keeping the query language strictly regular, jsongrep guarantees predictable performance regardless of query complexity. You give up expressiveness - no filters, no arithmetic - and get a tool you can reason about.
On a 190MB dataset, the end-to-end benchmark isn't close.
\nKepe is upfront about the tradeoffs: jsongrep is a search tool, not a transformation tool, just really fast path matching. The article also walks through Glushkov's construction and subset construction in practical detail, which is worth the read on its own as a comparison to Ken Thompson's NFA construction.
Nir Barak's rewrite of JSONata in Go for Reco's pipeline is a different problem solved at the architecture level.
\nReco's policy engine evaluated JSONata expressions against billions of events. The reference implementation is JavaScript; the pipeline is Go. Every evaluation crossed a language boundary via RPC - roughly 150 microseconds of overhead before any actual work happened.
\n\n\nRear Admiral Grace Hopper has a famous presentation about how time adds up. 150 microseconds isn't much, but when you have a lot of 150 microsecond traversals...
\n
Their solution was gnata: a pure-Go JSONata 2.x implementation with a two-tier evaluator. Simple expressions take a fast path that operates on raw bytes without parsing the document. Complex expressions go through a full parser, and the RPC fleet is gone.
\nTheir claim: the total build time was one day, with a token cost of $400, saving them potentially half a million dollars a year.
\nThe article is also honest about what came after: building gnata was day one; shadow-mode validation against production traffic was the rest of the week. But there's more; they also caught bugs in the reference JSONata implementation along the way - wins on multiple fronts.
JSON querying at scale rewards investment that most teams defer until it's already expensive. That's a pattern that goes beyond JSON, too.
\njsongrep is interesting as a computer science artifact - the DFA approach is elegant and the benchmarks back it up. gnata is interesting as a production story - the methodology (port the test suite, implement until it passes, validate in shadow mode) is directly reusable for any language-boundary problem in your own pipeline.
Both are worth reading.
","excerpt":"Two recent articles tackle JSON querying performance from opposite ends: one applies automata theory to eliminate interpretation overhead at query time, the other kills a $500K/year language-boundary tax by rewriting a JavaScript reference implementation in Go. The methodologies are different; the lesson is the same.","authorId":"019c5c8a-609d-7cd4-975b-50bbcc412a33","authorDisplayName":"dreamreal","status":"APPROVED","publishedAt":"2026-03-27T12:27:10.942Z","sortOrder":0,"createdAt":"2026-03-27T12:27:07.462192Z","updatedAt":"2026-03-27T12:29:16.184766Z","commentCount":0,"tags":["go","json","optimization","query","rpc","rust"],"categories":[],"markdownSource":null}