Query Language Ports Have Enormous Leverage. AI Just Made Them Feasible in a Day.

A team at Vine used AI to port JSONata to a new runtime, shipped it in a day, and cut their infrastructure bill by $500,000 annually. Simon Willison covered the writeup. The speed is the headline, but the economics are the part worth examining.

What JSONata Actually Is

JSONata is a declarative query and transformation language for JSON. Think XPath but for JSON objects, with syntax that supports aggregation, lambda functions, and structural transformation in a single expression.

A basic path expression with a predicate:

$.Account.Order[Price > 10].ProductID

A transformation that sums order totals across nested structures:

$sum(Account.Order.(Price * Quantity))

The language was developed by Andrew Coleman at IBM and sits at the core of IBM App Connect, Node-RED, and a significant slice of the enterprise API gateway ecosystem. The reference implementation is a pure JavaScript package evaluated against an in-memory JSON object. No compilation step, no external state, purely functional evaluation against a document.

That “purely functional, no external state” property matters enormously for porting. The semantics of JSONata are fully captured by its conformance test suite. Pass every test, and your port is correct. That is not true of most systems worth porting.

The JavaScript Tax at Scale

The reference implementation’s language choice carries real costs at high concurrency. V8 is an excellent engine, but Node.js processes are single-threaded by design. Handling concurrent JSONata evaluations across many requests requires multiple processes or worker threads, which means multiple V8 heaps, separate GC cycles, and memory overhead that scales directly with concurrency.

For a platform processing user-submitted JSONata expressions as part of an integration or API transformation layer, this compounds. JSONata evaluations are typically short-lived and CPU-bound: parse the expression, traverse the AST against the input document, return a value. That workload profile is close to worst-case for a GC-managed runtime. Every evaluation allocates an AST, a traversal stack, and various intermediate values. V8 handles this fine at low concurrency. At thousands of concurrent evaluations, GC pressure becomes a measurable part of the latency budget, and process-level isolation adds memory overhead that does not go away.

A port to Go changes the math substantially. Goroutines are cheap enough to evaluate thousands of JSONata expressions concurrently without the overhead of spawning separate processes. The GC pressure is lower because you are not fighting JavaScript’s heap fragmentation model. Per-goroutine memory overhead is kilobytes rather than the megabytes that come with isolating Node.js workers from each other.

The $500K/year figure implies a meaningful compute fleet. At AWS pricing for compute-optimized instances, that represents hundreds of cores handling JSONata evaluations continuously. A 2-5x improvement in throughput per core, applied across that fleet, reaches half a million without difficulty. The savings are a straightforward consequence of matching the runtime to the workload.

What the AI Did and Did Not Do

Porting a query language implementation is a well-understood category of work: study the spec, translate the reference implementation, verify against the test suite. The JSONata reference implementation is approximately 5,000 lines of JavaScript. It has a lexer, a parser, an AST, a static analysis pass, and an evaluator. Each component has a clear structural equivalent in Go or Rust.

Before capable AI coding assistants, porting this took weeks to months. You would translate the parser by hand, fight the type system on both sides, and work slowly through the test suite catching semantic divergences. The IBM-maintained Java port, JSONata4Java, required significant engineering effort across multiple months. The community Go port, jsonata-go, accumulated contributions over years before reaching solid spec coverage.

With an AI assistant handling the translation, the mechanical work collapses. The model understands JavaScript well enough to translate function logic into idiomatic Go: Array.isArray becomes a type switch, closures become function values with explicit captures, prototype methods become receiver functions. Each module translates in minutes rather than hours. Getting a version that compiles and handles the common cases can happen in a single day.

AI handles the mechanical translation. Correctness at the spec level is still the test suite’s responsibility. The value of an AI coding assistant here is specifically in compressing calendar time on the translation step, not in eliminating the need for correctness verification. Getting the full test suite passing still requires engineering judgment about edge cases in type coercion, sequence handling, error propagation, and the precise behavior of every built-in function.

The Test Suite Is the Load-Bearing Part

JSONata ships with a comprehensive conformance suite covering hundreds of cases: operator precedence edge cases, type coercion semantics that differ from JavaScript’s own coercion rules, the handling of undefined values in path expressions, and the full behavioral spec for built-in functions like $reduce, $zip, $formatNumber, and $eval.

The test suite is the actual specification for implementors. The prose documentation clarifies intent; the tests specify behavior.

Any port of JSONata is only as trustworthy as its coverage against that suite. The existing Go port tracks this explicitly, noting which test categories pass and which remain incomplete. If Vine’s port was passing the full suite at the end of that day, the test suite did the safety work. The AI translation was the fast part; compliance verification was the part that determined whether they could actually ship it.

This is the broader point for AI-assisted porting in general. AI compresses the coding time, but it does not change what needs to be verified. A port that handles 95% of expressions correctly but diverges on type coercion edge cases will fail silently in production when a user writes the expression that triggers the gap. The coverage requirement does not go away; only the time to get to initial coverage does.

Language Ports as Infrastructure Leverage

The deeper pattern here is that language ports of foundational libraries have always had disproportionate infrastructure value when the library sits in a hot path. If a library runs on every request, the runtime choice matters more than most other optimizations. JSONata in an integration platform evaluates on every message transformation; the overhead compounds directly into cost.

Previously, the engineering cost of a correct port was high enough that most companies found workarounds. Run the JS implementation in isolated workers. Scale horizontally to compensate for single-threaded limits. Accept the overhead as a cost of doing business. The time investment to build a port with full spec compliance and passing test coverage was weeks of senior engineering time, and for many teams the ROI calculation did not close.

AI changes the cost curve without changing the shape of the problem. The translation step is now hours rather than weeks. That shifts the calculation for a category of ports that were previously worth doing in principle but not worth the calendar time in practice.

JSONata sits near the ideal end of this spectrum: well-specified, purely functional, with a conformance test suite that defines correctness precisely. There are libraries that are harder to port because they have I/O semantics, OS-specific behavior, or spec ambiguities that no test suite resolves. But for the category that JSONata represents, the playbook is now clear. Identify the performance gap, verify that a conformance suite exists to validate the port, use AI to do the translation, and let the tests determine when you are done.

Half a million dollars a year is a concrete demonstration of what that math looks like when the workload is right.