Deno vs. Node.js vs. Bun Performance & Comparison (2026)

In this video, we'll compare Deno with Bun and Node. js and see which one you should try for your next project. In the first test, we'll measure the performance of the bare-bones framework itself and measure GET request latency, throughput, CPU usage, memory usage, as well as availability and CPU throttling by Kubernetes. And the goal is to find out which framework can handle the most requests per second with the lowest latency. In the second test, we'll add a Postgres database, and each application, after receiving a POST request with a JSON payload, will parse the JSON and save that object in the Postgres database. In addition, we'll measure the Postgres CPU usage itself, as well as the connection pool size maintained by each application. To run the test, I created an EKS cluster with nodes dedicated for each application, and I ran exactly two instances on each node to utilize all CPU cores, which in this case are 2, and each instance is limited to a 1 CPU limit. In the first test, I just generate as many requests per second as each app can handle, and for the second test, I add another storage-optimized EC2 instance to run Postgres. And as you can see, here are EC2 instances in my AWS account. Alright, let’s go ahead and run the first test. The entire test took around 2 to 3 hours just because I wanted to slowly increase the load on each application. Let me run this test for a minute or so and we’ll go over the results at the end. First, we have throughput, and Bun once again showed the best result, and even compared to my previous benchmarks, it made some improvements as well. Second place for Node. js and the last one is Deno. Next, we have latency, which would just correlate to the requests per second graph and when each application started to degrade latency spikes. Then we have CPU usage. Memory usage graph. CPU throttling by Kubernetes. And that’s pretty much all. Bun is clearly the fastest JavaScript framework when it comes to static HTTP requests. In the second test, we’ll have a Postgres database and more or less a real-world use case. For each application, I set a 250 database connection limit for each instance, and I have 2 instances per framework. Now, Bun for some reason immediately creates all those connections, but Deno and Node slowly increase the number of connections while I increase the load. But by the end of the test, it drops to a lower number. It’s outside of my control; it's just the behavior of different Postgres drivers. By the way, you can find the source code in my public GitHub repo. Alright, let me run this test for a minute as well, and we’ll go over the results.

First, we have requests per second, and Bun performed again better than the others by a significant difference. Keep in mind, Bun has a very well-optimized native Postgres driver, whereas Deno and Node. js use the same open-source driver. Next, we have latency. Connection pool size. I used the Postgres Prometheus exporter to collect the number of active connections per application. Then, CPU usage. And finally, memory usage. Well, those are the results. Bun clearly performs much better than Node. js and Deno in these common use cases, mostly because it has very low-level optimizations like the Postgres driver, and it has a bunch of others like S3 and more.