benhaney
Jsonrs is a JSON library like Jason or Poison, but it’s faster and uses much less memory. This is thanks to the core of it being a Rust NIF leveraging Rust’s excellent serialization framework, serde.
Recently, Jsonrs started using rustler_precompiled, so you no longer need an entire Rust toolchain in your build pipeline in order to start using Jsonrs in your project! This was a significant blocker for a lot of people in adopting Jsonrs before, so I’m excited that there’s such a good solution to it now, and I hope it breathes some life back into Jsonrs.
Since the main purpose of Jsonrs is performance, I’ll talk a little about that here so you can evaluate if it’s worthwhile for your use-case:
- The primary benefit of Jsonrs, and what it was originally built to solve, is reducing memory usage when encoding large objects into large JSON strings.
- While encoding large objects that resulted in ~80MB JSON strings, Jason was using gigabytes of peak memory and resulting in OOM-kills. Jsonrs was created to fix this particular production issue, and was able to do the same encode using just the 80MB of the resulting string (plus 12 bytes of additional memory), and at around 5 times the speed.
- Jsonrs’s performance advantage shrinks as the data being worked with gets smaller and less complex. You’re only going to see a big difference with fairly large or complex JSON.
- OTP 24’s JIT noticeably improved the run time performance of Jason and Poison, so the performance gap has gotten a bit smaller since Jsonrs was first created. The memory usage gap doesn’t seem to have changed much from what I’ve seen, and is still very dramatic.
So the target demographic for Jsonrs is applications doing large JSON encodes, and these applications are likely to see a huge improvement in memory usage and a smaller but still significant improvement in speed.
I used to say that it isn’t worth using Jsonrs for people who aren’t dealing with encoding fairly large objects. If you aren’t going to see a huge difference in performance, why deal with the friction of building a Rust NIF in your project?
But now that precompiled libraries are available for common platforms, the barrier to using Jsonrs is much lower, and it might now be worth it for more people to use. I expect that you won’t see much of a difference if your application isn’t in the target demographic, but if you ever wanted to try it out anyway, now is a great time!
Where Next?
Trending in Announcing
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Master modern tools, write cleaner code, and tackle real-world challenges with Manning books, videos, and courses. Start building today.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #ai
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #blog-post
- #ecto-query
- #elixirconf-us
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
Producing high quality Elixir screencasts since 2017.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 6- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
cjbottaro
We have this exact use case. We use Elixir to read Postgres CDC and write transactions as JSON to Nats Jetstream. We just kept increasing our Koob pods memory limit to work around the problem.
benhaney
Oh yeah that definitely sounds like an ideal use case. If you try out Jsonrs for that I’d love to hear about it.
adammokan
Great library @benhaney !
I rolled this into strategic portions of my data processing systems yesterday and I’m honestly a bit shocked at the difference I’m seeing on the memory usage.
kartheek
Nice - can you share some metrics if it is possible?
adammokan
Looking at the metrics overnight and digging into the amount of data processed - I see nearly a perfect 50% decrease in memory usage on our average inputs and in the largest 10% of the input payloads it is showing close to a 65% memory decrease.
Unfortunately the data we process could be considered “consistently inconsistent” and really depends on our customers’ behavior in various other platforms as we integrate with dozens of 3rd party systems and synchronize / process that data. Meaning that we have a range of input documents that can be as small as 50kb and as large as 25mb in size. My current customer workload averages just over five million of these transactions each day.
Another thing I should note is that my changes were purely around JSON decoding as that was the biggest area for improvement due to that wide range of document sizes and inconsistency there.
So take all of this as a grain of salt, given the variables at play.
benhaney
Glad to have a real-world scenario that flexes decoding and still sees fairly substantial improvement. Until now, I’ve only seen large real-world use of Jsonrs in encode-heavy workloads, since that’s primarily what it’s been developed for. Thanks for sharing this!