It’s been only a few days since the Bun 1.0 announcement and it’s taken social media by storm! And rightly so.
Bun promises better performance, and Node.js compatibility and comes with batteries included. It comes with a transpiler, bundler, package manager and testing library. You no longer have to install 15 packages before writing a single code line. It creates a standardised set of tools and addresses the fractured nature of the Node.js ecosystem.
So what’s there not to like about this?
And because Node.js is still the most popular language on AWS Lambda, one can ask “Should I consider switching my Node.js functions to Bun?”
Before you do, here are a few things you should consider.
Worse cold start performance
The AWS Lambda team has done many optimizations for the official runtimes to improve their performance. Consequently, cold start performance has improved year-on-year.
But Bun is not an officially supported runtime so you have to use a custom runtime and miss out on those optimizations. As a result, Bun functions have a much higher cold start duration.
Mitchell Kossoris did a great benchmark test and the results are telling (lower is better):
(The test measures the total response time, not just the initialization time.)
Warm performance
In the same benchmark, Mitchell also found that Bun performs considerably better for CPU-intensive tasks (lower is better).
(This test function sorts 100k random numbers ten times)
Lambda is charged by the millisecond, so every ms of execution time saved is money in the bank. And if the function is not handling user-facing API requests then the elongated cold start time will not affect your user experience.
For these functions, the performance improvement is a compelling reason to switch to Bun. So long as the libraries you use are compatible with Bun (see the next point).
However, over 95% of Lambda functions I have ever seen are IO-heavy and won’t see any meaningful performance gains.
Lack of backward compatibility
At the time of writing, Bun still hasn’t implemented many of Node.js’s APIs (see the official list here). As such, many popular libraries such as Fastify and Pino are not compatible with Bun.
Also, Matteo Collina shared some insights and thoughts on why Bun is faster than Node. One of the reasons is that Bun prioritizes speed over backward compatibility:
Bun did not care about backward compatibility with a significant portion of the npm ecosystem. They made things fast and are working to preserve backward compatibility as an after-fact: this is how you approach building fast software. Conversely, Node.js processes are built around protecting the ecosystem instead. We know how to make Node.js faster, but doing so will create a lot of friction for the end users.
This should be a familiar story for anyone who’s had to maintain a system over many years. The constraint of keeping backward compatibility often means you can’t make the changes you need to make things fast.
Conversely, if your priority is speed and you try to retrofit backward compatibility as an afterthought. Then there’s every chance that you will never reach full compatibility or you end up losing most of the speed advantages you gained.
Unknown unknowns
Lastly, as a new runtime, there are still many problems and potential vulnerabilities that haven’t been identified yet, let alone addressed.
This is exacerbated by the fact that you have to use a custom runtime. So you can’t rely on the Lambda team to do the due diligence and to regularly update the runtime with the latest security patches.
If you operate in a regulated environment then it can also be difficult to get the sign-off from your CISO.
All and all, if security is important to you (as it should be for all of us!) then you might want to hold off for now. With the amount of hype around Bun at present, I’m sure security researchers are already looking into it.
Summary
In summary, the cold start performance and incompatibility with the AWS SDK represent immediate roadblocks for using Bun with Lambda.
The fact that it’s so new and there are many potential vulnerabilities that are yet to be discovered also makes me take pause.
So for most of you, I will recommend caution and patience between you use Bun in your production workload. Unless you absolutely need the performance improvements right now and cannot switch to a different language (such as Rust).
Did you know that the Bun logo is based on the Shanghai Dumpling (or Xiao Long Bao)? It’s a famous dish from the Shanghai region. And the way to eat it is to first poke a small hole to release the steam and the hot broth. Otherwise, you risk burning your mouth!
I think that’s a good analogy for the situation here.
You should experiment with Bun and see what it can and cannot do. Measure and compare the performance to see if there are tangible improvements for your application.
But please temper your excitement and don’t put Bun-backed functions in front of your users just yet!