JSONata was created by Andrew Coleman at IBM around 2016 and ships as the transformation language inside IBM App Connect Enterprise, Node-RED, and a range of IBM cloud integration services. The pitch is compelling: a concise expression language for querying and reshaping JSON that sits somewhere between XPath and a functional language.
Account.Order.Product[Price > 10].
{"name": Description, "cost": Price * Quantity}This navigates nested JSON structure, filters on a predicate, and reshapes the output, all in a single expression. The reference implementation is JavaScript, published as the jsonata npm package, and it’s genuinely good: a complete parser, a recursive evaluator, and a rich set of built-in functions covering string handling, math, date formatting, and array operations.
What it isn’t is cheap to run at serverless scale.
The Cost of a JavaScript Runtime at Volume
AWS Lambda charges by request count and duration multiplied by allocated memory. When you run JSONata transformations in a Node.js Lambda, every cold start pulls in the V8 JavaScript engine, initializes the runtime, loads your function handler, and only then starts executing. V8 is an engineering marvel, but it’s built for a browser or a long-running server process, not for a function that lives for 200 milliseconds and dies.
The memory footprint compounds the problem. A Node.js Lambda handling JSON transformations typically needs 128-256MB to run comfortably. The equivalent function compiled to a native binary, in Go or Rust, might run in 20-30MB while completing the same work in a fraction of the time. Lambda prices those two scenarios very differently.
Simon Willison’s coverage of the Vine team’s work puts the annual savings at $500,000. That figure implies a pipeline running at real scale: millions of JSON transformation invocations per day, every one paying the JavaScript overhead tax. At that volume, the inefficiency stops being a footnote and becomes a line item worth engineering around.
Why JSONata Wasn’t Ported Before
Complete, production-ready ports of JSONata to other languages have been elusive. IBM maintains JSONata4Java, a Java port that is actively developed but has historically lagged the JavaScript reference on edge cases. Rust experiments have appeared but never reached feature parity. The JavaScript implementation keeps moving forward; the ports trail behind; teams decide it’s safer to stay on the reference implementation.
The difficulty isn’t the core algorithm. JSONata’s evaluator is a recursive descent interpreter, and the fundamental structure translates directly to most typed languages. The difficulty is in the details: the sequence semantics (how single values and arrays behave differently depending on context), the error propagation model, the type coercion rules, and the hundreds of built-in function edge cases that only surface once you run a comprehensive test suite.
Writing a correct port by hand means understanding all of that well enough to replicate it without missing anything. That’s months of work for a careful engineer, and most teams look at that estimate and decide to keep paying the serverless overhead instead.
What AI Changed About the Calculation
The Vine team’s approach is representative of a method that has become reliable over the past year: use a capable language model as a mechanical translator, use the existing test suite as the acceptance oracle, and iterate until the pass rate reaches acceptable levels.
This method works well for JSONata specifically because of how its test suite is structured. Each test is a self-contained document with an input JSON object, a JSONata expression, and an expected output. That structure is language-agnostic by design. The same test files that validate the JavaScript implementation can validate any port, without modification. You’re not writing new tests or manually specifying behavior; you’re running the specification that already exists.
A plausible workflow looks roughly like this: feed the parser module to the model with a request to translate it to the target language, then feed the evaluator, then the built-in functions. Run the test suite. Feed failures back with surrounding context. Repeat. The human contribution shifts from writing code to orchestrating the process: reviewing the structural choices the model makes, confirming that idioms in the target language are being used sensibly, and handling the small fraction of failures that require semantic understanding rather than mechanical translation.
“In a day” is credible for this approach on a library of JSONata’s size. The test suite handles correctness verification continuously, which means you get fast feedback and don’t have to maintain a mental model of every edge case yourself. The model handles the tedious part; you handle the judgment calls.
The Test Suite as Specification
The deeper lesson here isn’t about JSONata specifically. It’s about what makes a library portable at all.
JSONata was portable because its test suite is its specification. When the test documents describe every behavior precisely enough that a model can use them as a correctness target, you’ve effectively decoupled the specification from the implementation language. That’s a meaningful design property, and not every library has it.
Libraries with behavior that depends on JavaScript runtime specifics, such as prototype chain behavior, event loop semantics, or garbage collection timing, are harder to port regardless of how capable your model is. Libraries whose tests mock their own internals are harder, because those tests don’t validate observable behavior at the system boundary. Libraries with no tests at all are essentially undocumented at the behavioral level; you’d have to reconstruct the specification from usage examples and source reading before you could even begin.
The jsonata-js test suite has hundreds of cases covering each operator, each built-in function, and the interactions between them. That density is what made a one-day port plausible rather than a one-month project.
Runtime Choice and the Economics That Follow
For a JSONata port aimed at serverless cost reduction, Go and Rust are the natural targets. Go Lambda functions using the provided.al2023 runtime start in under 10 milliseconds, use a fraction of the memory of Node.js, and produce binaries with no external runtime dependency. Rust offers better raw throughput, at the cost of a steeper learning curve and longer compilation cycles. Either one changes the economics of running a query engine at high volume.
The math is straightforward. If a Node.js JSONata Lambda takes 150ms and uses 128MB, and a compiled equivalent takes 15ms and uses 32MB, you’ve reduced the duration component by 90% and the memory component by 75%. Lambda billing reflects both dimensions. At $500K/year in savings, the previous spend on JSONata transformations was somewhere north of $500K annually, which is entirely plausible for a data integration platform processing millions of events per day.
For teams running similar pipelines, the question is no longer whether porting is worth it. The question is whether your query engine has the test coverage to make an AI-assisted port reliable. JSONata did. If your transformation layer is built on a library with a weaker test suite, the first investment might be writing those tests before attempting the port.
What Comes Next for the Ecosystem
The JSONata specification tests were written against JavaScript behavior. If a compiled port passes all of those tests and runs an order of magnitude faster, teams building integration tooling face a choice about which implementation they treat as authoritative. IDE integrations, linters, and expression validators for JSONata have mostly been built on top of the JavaScript library. Whether the ecosystem migrates toward a faster compiled core, or whether the two implementations drift on edge cases over time, depends on whether the port gets maintained with the same rigor as the original.
That’s a healthy problem for a query language to have. It means the language has outgrown its original runtime context and is valuable enough to exist in multiple forms. JSONata has been quietly powering enterprise data pipelines for nearly a decade; the fact that it’s now worth porting to save half a million dollars a year is its own kind of validation.