Introduction In the world of server-side JavaScript environments, Node.js has remained the de facto standard for over a decade, widely used in large-scale production systems across a variety of domains. However, in recent years, alternative runtimes such as Deno and Bun have emerged with their claimed performance advantages and modern architecture. Deno, introduced by the original creator of Node.js, was designed to address the limitations of Node.js by offering enhanced security, a modern module system, and TypeScript support out of the box. Bun, on the other hand, is a newer entrant focusing primarily on high-performance execution, rapid startup times, and an integrated toolchain. Both Deno and Bun present benchmarks that suggest substantial performance improvements over Node.js (Sometimes 4x to 5x). However, these benchmarks are frequently based on highly simplified examples, such as "Hello World" HTTP servers, which do not reflect the complexities of real-world applications. To understand and confirm the claims, this article presents a comparative performance analysis of Node.js, Deno, and Bun using a realistic case study: a URL shortener service. Unlike minimal benchmarks, this application simulates a production-grade workload involving routing, input validation, database access, and asynchronous operations. The goal of this investigation is to assess whether the published performance gap between these runtimes can still be seen under practical conditions, and to determine if the claims of superior performance hold true when applied to real-world cases. By evaluating these runtimes under real-world workloads, this article aims to validate the claims, thereby helping developers and architects choose the right runtime for their upcoming projects. Test setup All benchmarks were conducted on a MacBook Pro with an Apple M2 chip, featuring 12 CPU cores and 16 GB of RAM. To ensure high-quality load generation, the widely recognized Bombardier tool was used. The tool was customized to send a random and unique URL in the request body, formatted as a JSON string. Bombardier Bombardier was configured to simulate a constant load of 100 concurrent connections, completing a total of 1M requests per test. The following software versions were used, all up to date at the time of testing: Node.js: v24.4.1 Deno: v2.4.2 Bun: v1.2.18 Node.js: v24.4.1 Node.js Deno: v2.4.2 Deno Bun: v1.2.18 Bun For each runtime, the fastest available web framework was selected to ensure optimal performance: Node.js application: built with Fastify Deno application: built with Hono Bun application: built with Elysia Node.js application: built with Fastify Node.js Fastify Deno application: built with Hono Deno Hono Bun application: built with Elysia Bun Elysia All tests interacted with a PostgreSQL database, a widely adopted open-source object-relational database system with over 35 years of development. PostgreSQL is well-known for its reliability, extensive feature set, and strong performance. PostgreSQL A single table named shortenedurls was used for all database operations. This table stores both the original and shortened URLs. Its structure is as follows: shortenedurls Before each test, the table is truncated so that the index doesn’t get oversized and slow down the application running later in the test cycle. Applications Each application uses a distinct web framework, resulting in slight differences in application implementation. However, the core functionality remains consistent. A URL shortener application has been chosen for benchmarking, as it represents a real-world use case while remaining simple enough for controlled testing. The application evaluates performance across the following operations: JSON parsing from the incoming request Request validation Database read via an ORM JSON response construction JSON parsing from the incoming request Request validation Database read via an ORM JSON response construction The implementation for each application is detailed below: Node.js https://gist.github.com/mayankchoubey1/9d30a9dcabd6f3ec8792479d18265c52?embedable=true https://gist.github.com/mayankchoubey1/9d30a9dcabd6f3ec8792479d18265c52?embedable=true Deno https://gist.github.com/mayankchoubey1/91e56e8dfca00c0ed83ab39a460463bd?embedable=true https://gist.github.com/mayankchoubey1/91e56e8dfca00c0ed83ab39a460463bd?embedable=true Bun https://gist.github.com/mayankchoubey1/b2e05bfbb200222cde222cd0847e9fed?embedable=true https://gist.github.com/mayankchoubey1/b2e05bfbb200222cde222cd0847e9fed?embedable=true Results Each test is conducted with a total of 1 million requests. The following performance metrics are recorded for each test run: Total time to complete 1 million requests Requests per second (RPS) 25th percentile latency Mean latency Median latency 75th percentile latency Maximum latency CPU usage Memory usage Total time to complete 1 million requests Requests per second (RPS) 25th percentile latency Mean latency Median latency 75th percentile latency Maximum latency CPU usage Memory usage It is important to note that resource consumption—specifically CPU and memory usage—is as critical as raw performance. A faster runtime that incurs significantly higher resource costs may not provide practical value in real-world scenarios. The results in bar chart form are presented below: All the results together in a tabular form are as follows: Conclusion In summary, while Bun and Deno demonstrate slightly better performance than Node.js, the difference is marginal. Node.js delivers approximately 12K requests per second (RPS), compared to 12.4K from Deno and Bun. This does not represent a significant performance gain—certainly not the 2x or 3x improvement often claimed. Therefore, any decision to migrate away from Node.js, a longstanding leader in the JavaScript runtime ecosystem, is unlikely to be driven by raw performance metrics. Instead, such a move would more likely be motivated by other factors, such as native TypeScript support, a built-in permissions model, modern runtime architecture, or deployment features like Deno Deploy. In essence, performance alone does not justify abandoning Node.js; the advantages lie elsewhere.
