Node.js does not need to win every benchmark to be a great choice. Its advantage is the balance between performance, compatibility, ecosystem, operational tooling, and available expertise.

Introduction: maturity is also a technical feature

Every so often a runtime appears that promises to run JavaScript faster, simplify tooling, or rethink how we build backend applications. Bun and Deno have pushed the conversation in that direction, and that is positive: they force us to revisit assumptions we took for granted for years.

But there is a question that deserves more attention than the requests-per-second ranking:

What makes a platform a good decision for building and maintaining software over years?

Performance matters. So do library compatibility, database drivers, observability tools, deployment processes, how easy it is to hire or train the team, and how quickly you can diagnose problems in production.

Node.js stands out for the balance of those factors. That does not mean it is always the fastest option, or that its alternatives are not ready for real cases. It means that, for a wide variety of systems, it reduces technical uncertainty.

This article explores how Node.js works, what it offers today, which limits it still has, and when it makes sense to choose it over newer alternatives.

1. What is Node.js really?

Node.js is a JavaScript runtime outside the browser. It lets you use JavaScript to build HTTP servers, APIs, command-line tools, integration processes, workers, and many other applications.

Its architecture combines several pieces:

• V8: the JavaScript engine developed by the Chromium team.
• libuv: the library that provides the event loop and an abstraction layer for asynchronous system operations.
• Node.js APIs: modules for files, networking, processes, cryptography, streams, workers, and more.
• Modules and packages: Node’s module system and the huge ecosystem published on npm.
• External tools: package managers, frameworks, compilers, linters, tests, profiling, and observability.

It is a mistake to describe Node as “a single thread that cannot do several things at once.” JavaScript execution for an instance usually happens on a main thread, but the runtime can also coordinate asynchronous I/O operations, use libuv’s thread pool for certain tasks, and create Worker Threads for CPU-intensive work.

That distinction matters: concurrency is not the same as parallelism. Node can manage many concurrent I/O operations without creating a JavaScript thread per request. To take advantage of multiple cores for intensive JavaScript computation, you need to explicitly design the use of workers or processes.

2. The event loop: why it works so well for I/O

A web API usually spends a large part of its time waiting: a PostgreSQL query, a response from an external service, a file read, a network operation, a cache, or a message broker.

If the code blocks the thread while waiting for each result, the server wastes capacity. Node.js lets you start many asynchronous operations and keep processing other tasks while their results arrive.

A simplified flow would be:

1. An HTTP request arrives.
2. The code validates the input and starts an asynchronous query.
3. While the database responds, the event loop can handle other ready tasks.
4. When the result arrives, the corresponding flow resumes.
5. Node builds and sends the response.

The advantage is not “making any function fast.” The advantage is using resources well when the system has many pending I/O operations.

The limit: blocking the event loop

A heavy synchronous computation can prevent the main thread from processing other requests. The same can happen with a very costly CPU operation, an inefficient algorithm, or huge serialization.

Examples of work that deserves careful analysis:

• generating hashes or processing images at large volumes;
• compressing or transforming large files;
• walking enormous data structures;
• running expensive regular expressions;
• performing intensive JavaScript calculations;
• processing massive payloads on the main thread.

Solutions depend on the case: optimize the algorithm, use asynchronous APIs, offload work to Worker Threads, separate processes, or move the work to a specialized service.

Practical rule: Node works very well when the event loop stays available and intensive work is distributed deliberately.

3. V8, libuv, and performance: what each piece contributes

V8: JavaScript optimization

V8 compiles and optimizes JavaScript during execution. Its performance depends, among other things, on the execution pattern, data types, memory allocations, and the stability of hot code paths.

There is no universal rule that a dynamic language is slow or that a runtime is fast in every case. An application can be limited by CPU, I/O, database, serialization, network, or an external dependency. If the dominant time is in a slow SQL query, changing the runtime will probably not solve the main problem.

libuv: asynchronous operations and thread pool

libuv provides the event loop and abstractions for I/O. Some operations, such as certain filesystem, DNS, or cryptography tasks, can use a thread pool. Not every asynchronous API uses the same mechanism: for example, network I/O on common systems is handled through operating-system notification mechanisms.

This has operational implications. Adjusting UV_THREADPOOL_SIZE can help in specific cases, but it is not a magic switch to speed up every query, nor does it increase every API’s capacity by itself. First measure which resource is saturated.

The full application is the relevant benchmark

In a real API, performance can depend more on:

• database queries and indexes;
• connection pool and latency;
• payload size;
• validation and serialization;
• authentication and cryptography;
• logs, metrics, and tracing;
• cache;
• CPU and memory limits;
• behavior under concurrency and spikes.

The runtime is an important piece, not the entire system.

4. Node.js in 2026: versions and support

At the end of October 2026, the official calendar (nodejs/Release) shows an important transition:

Branch	Status (approx. 27–28 Oct 2026)	Practical reading
Node.js 26	Becomes Active LTS (“Lithium”) on October 28, 2026	Preferred base for new services after that date
Node.js 24	Maintenance LTS since October 20, 2026	Still valid in production; plan migration to 26
Node.js 22	Maintenance LTS	Existing systems; support window until April 2027
Node.js 27	Alpha since October 28, 2026	Early testing only; not as a corporate base

Starting with Node.js 27 the project changes the release cadence: one major per year (April), a prior Alpha phase, and 30 months of LTS. Node.js 26 is the last line of the previous model (even LTS / odd Current). Always check the calendar before fixing a container base image.

Which version to choose?

For a new system after October 28, 2026, I would normally start with the latest patch of Node.js 26 LTS, unless a dependency or deployment platform requires another version. If the environment does not yet support 26, Node.js 24 Maintenance remains a reasonable option while the upgrade is planned.

To evaluate an Alpha or Current version, I would review:

• compatibility of libraries and native modules;
• support on the deployment platform;
• APM and security-agent behavior;
• deprecated or incompatible changes;
• update and rollback policy.

I would not use an EOL version for a new service. I also would not assume that a newer version automatically improves an application: it must be checked with functional and load tests.

5. TypeScript without transpiling: an important evolution

Node.js already offers built-in support for running a common subset of TypeScript through type stripping. In recent versions this functionality has stabilized. Node removes type annotations that do not require generating JavaScript code, but it does not perform static type checking.

This makes it easier to run scripts and simple TypeScript code without adding a transpiler to the execution path.

However, the built-in support has important limits:

• it does not replace tsc for type checking;
• it does not implement every TypeScript transformation that requires code generation;
• it does not apply tsconfig.json options the way a full compiler would;
• path aliases and other transforms may need extra configuration or tools;
• for a production application it can still make sense to compile, bundle, or use a runner such as tsx, depending on the architecture.

Official documentation: Node.js — TypeScript

A reasonable pipeline

A TypeScript project should not confuse “can run” with “is validated.” A pipeline can include:

1. tsc --noEmit to check types.
2. Unit and integration tests.
3. Linter and formatter.
4. Build or bundling if the application requires it.
5. Startup and integration tests against the final artifact.

The exact configuration depends on the application, but type checking should be an explicit stage if the project depends on it.

6. The ecosystem: an advantage that accumulates

Node.js’s main advantage is not a specific library, but the accumulated effect of its ecosystem.

HTTP frameworks

• Express: minimalist, well known, with a huge amount of middleware and examples.
• Fastify: prioritizes low overhead, efficient validation and serialization, plugins, and encapsulation.
• NestJS: offers modules, dependency injection, decorators, and a structured architecture; it can use Express or Fastify as the HTTP adapter.
• Koa: middleware with a smaller, more modern approach than Express.
• AdonisJS: a more integrated framework, with conventions for building full applications.
• Hono: a web-standards-based framework that can also run on Node and other runtimes.

They are not exact substitutes. Express and Koa offer a small core; Fastify focuses on an efficient, extensible HTTP layer; NestJS adds application structure and conventions. The framework choice changes the development experience and the overhead of a request.

Drivers, SDKs, and tools

Node.js has broad support in:

• PostgreSQL, MySQL, Redis, and MongoDB drivers;
• AWS, Azure, and Google Cloud SDKs;
• authentication, OAuth, and OpenID Connect;
• queue and messaging tools;
• OpenTelemetry, APM, profiling, and logging;
• testing, build, linting, and package management;
• native modules and OS integration tools.

That does not mean every package is safe, maintained, or of uniform quality. A large ecosystem also requires governance: updating dependencies, reviewing vulnerabilities, pinning versions, and removing unmaintained packages.

Why it matters in a company

An incompatibility does not only cost programming time. It can affect deploys, audits, observability, incident response, and vendor support.

That is why, in enterprise systems, compatibility of a critical SDK can weigh more than a 10% improvement in a synthetic benchmark.

7. Frameworks and performance: Express or Fastify?

A benchmark of frameworks running on Node.js shows something important: the framework and the request pattern also influence performance.

Fastify’s official benchmarks page shows a test updated on October 19, 2026, on a Linux x64 machine with 4 vCPU and 15.6 GB of memory, using Node.js 24.22.0. For a minimal GET endpoint that responds { "hello": "world" }, it reports:

Framework	Reported requests/s
Fastify 5.12.7	91 539
Hono 4.13.13	88 776
Koa 3.2.1	75 523
Express 5.3.0	68 966

In the POST scenario with a JSON body that is parsed and returned, the same page reports:

Framework	Reported requests/s
Fastify 5.12.7	72 691
Hono 4.13.13	62 945
Koa 3.2.1	48 266
Express 5.3.0	46 005

Source: Fastify — Benchmarks

How to interpret those numbers

They are data from a controlled scenario, useful for comparing relative overhead in that configuration. They are not a performance promise for any application.

They do not necessarily include the work that dominates a business API: remote database queries, authentication, business rules, complex validation, third-party calls, logs, or tracing.

Also, framework benchmarks can vary by version, machine, server options, engine warm-up, and load tool. Before turning them into an architecture decision:

• review the methodology and benchmark code;
• confirm the Node and framework versions;
• reproduce the test in your environment;
• add a representative endpoint from your application;
• record throughput, p50, p95, p99, errors, and memory.

The reasonable conclusion is not “Fastify will always be 1.3× faster in production.” It is that its overhead in those minimal scenarios is competitive and worth evaluating if HTTP performance matters.

8. Scalability: how to use multiple cores

A Node.js instance does not automatically run all of your application’s JavaScript in parallel across every core. There are different strategies to scale, each with costs and different uses.

Scale horizontally

Running several replicas of the service behind a load balancer is a common strategy. Each process has its own event loop and memory. This makes it easier to scale by containers or machines, but requires thinking about sessions, local caches, connections, scheduled tasks, and coordination between instances.

Cluster or multiple processes

The cluster module lets you create Node processes that can share a server port. In modern environments it is also common for the orchestrator to run several replicas instead of each container managing many internal workers.

There is no single strategy: it depends on the deployment model, availability, isolation, and operational tools.

Worker Threads

Worker Threads lets you run JavaScript in separate threads and share data in a controlled way. It is useful when there is CPU-intensive work that can be split, but it has communication and management costs. You usually do not need to create a worker for every web request.

Queues and asynchronous processing

For long-running work — report generation, image processing, bulk imports, or batch sending — it is often better to take the work out of the HTTP response cycle and process it in workers connected to a queue.

The architecture can look like this:

1. The API validates the request.
2. It registers a job and sends it to a queue.
3. A worker processes the job.
4. State is saved and the client is notified when it finishes.

This improves resilience and lets you scale processing separately. Changing the runtime does not replace this kind of decision.

9. Observability and production diagnostics

A mature platform needs more than console logs. Node.js offers tools and an ecosystem to identify where time is spent and what is happening in production.

What to measure

• Latency: p50, p95, and p99 per endpoint.
• Throughput: requests per second and volume per route.
• Errors: 4xx, 5xx, timeout, and dependency-failure rates.
• CPU usage: per process, container, and operation when possible.
• Memory: RSS, used heap, sustained growth, and GC pauses.
• Event loop: delays that indicate blocking or saturation.
• Dependencies: duration of SQL queries, HTTP calls, and queue operations.
• Saturation: connections, database pool, sockets, and system limits.

Useful tools

• node --inspect and V8 profiling tools;
• node --cpu-prof to generate CPU profiles;
• node --heap-prof to investigate allocations and memory;
• perf_hooks for timing instrumentation;
• process.memoryUsage() for memory observations;
• OpenTelemetry and compatible APM tools for traces, metrics, and request correlation.

Options and concrete availability depend on the Node.js version; check the official documentation before incorporating them into an operational procedure.

Do not optimize blindly

If an API is slow, follow the evidence. It may be a missing index, a small connection pool, a slow external dependency, costly serialization, or an event-loop block. A runtime change should come after identifying the bottleneck, not before.

10. Security and maintenance

Node.js does not include the same default permission model as Deno. Code running inside a Node process usually has the permissions of the operating-system user it runs as. That does not make Node insecure, but it means security depends on additional layers: system permissions, containers, network policies, secrets, dependencies, and configuration.

Good practices:

• run processes with least privilege;
• avoid running as root unless necessary;
• keep Node and dependencies updated;
• generate and review a lockfile;
• scan dependencies and address vulnerabilities;
• keep secrets out of code and artifacts;
• limit network and filesystem access;
• define CPU, memory, and connection limits;
• validate input data and use parameterized queries;
• review dependencies that install or run scripts during installation.

The large availability of packages is an advantage, but it also widens the risk surface. Ecosystem governance is part of the architecture.

11. Real disadvantages of Node.js

An honest comparison must also acknowledge the costs.

Fragmented tooling

It is common to combine Node.js with a package manager, TypeScript, a test runner, a formatter, a linter, a bundler, and development tools. This offers flexibility, but increases the number of decisions and configurations.

Bun and Deno bet on a more integrated experience. If a project is small, having fewer pieces can improve onboarding and reduce friction.

Dependencies and compatibility

The breadth of the ecosystem does not guarantee quality. Some dependencies are abandoned, have vulnerabilities, or force old versions of other packages. Updates require an active policy.

CPU-intensive work

Node can run intensive work, but it should not block the event loop with long calculations. You need to use workers, processes, queues, or specialized services when appropriate.

Memory consumption and startup

Memory consumption and startup time depend on the code, loaded modules, configuration, and environment. There is no universal figure for “Node uses X MB.” In serverless applications or CLIs, startup can be an important criterion and must be measured.

It is not always the best tool

If a team needs a runtime with built-in explicit permissions, Deno deserves evaluation. If it wants integrated tools and gets measurable benefits in startup or throughput, Bun deserves a trial. Node’s maturity is an advantage, not a reason to dismiss alternatives without measuring them.

12. When to choose Node.js?

I would choose it when…

• the system depends on SDKs and libraries that are mainly tested on Node;
• a widely known, easy-to-operate platform is needed;
• the organization already has mature pipelines, observability, and practices for Node;
• the chosen framework and its plugins have official Node compatibility;
• the cost of an incompatibility is high;
• the priority is delivering features with controlled operational risk.

I would evaluate other options when…

• startup time has a direct impact on cost or experience;
• a representative load shows an important benefit with another runtime;
• the service can use web standards and has few Node-specific dependencies;
• execution permissions are a design priority;
• you want to consolidate development tooling into a single tool.

Decision matrix

Criterion	Suggested weight	Question
Compatibility	High	Which critical dependencies are officially supported?
Real performance	High if SLOs are demanding	Which runtime meets the goals at the same cost?
Observability	High in production	Do APM, tracing, profiling, and alerts work?
Security	High in every project	How are permissions, network, and secret access limited?
Productivity	Variable	What configuration and tools does the team need?
Team experience	High	Which option can the team maintain confidently?
Portability	Variable	Do you need to move code between runtimes or platforms?
Migration risk	High in existing systems	What would an incompatibility in production cost?

Not every criterion should carry the same weight. In a high-traffic public API, performance and observability can weigh heavily. In an enterprise system with hundreds of integrations, compatibility and maintenance can be decisive.

13. Architecture recommendation

For a new business API, a sensible base can be:

• Node.js on the active LTS branch (26 starting October 28, 2026);
• TypeScript with type checking in CI;
• Fastify if you want low overhead and a plugin model; NestJS if the team needs a more structured architecture and shared conventions;
• a compatible, maintained database driver;
• explicit input and contract validation;
• structured logs, metrics, and tracing;
• unit, integration, and end-to-end tests;
• containers and defined operational limits;
• load tests before scaling decisions;
• regular updates of Node and dependencies.

This is not a universal recipe. A small microservice may need less structure; a large platform may require standards and shared internal libraries. Architecture should respond to the domain, the team, and operational requirements.

Conclusion

Node.js remains a solid decision because it combines a modern engine, an efficient model for I/O, operational tooling, mature frameworks, and a broad ecosystem. Its main strength appears when we look at the full software cycle: develop, integrate, test, deploy, observe, and maintain.

Its limits are also real. The event loop can block, tooling requires choices, dependencies demand governance, and other runtimes can offer a more integrated experience or performance advantages in concrete scenarios.

That is why I would not choose Node.js out of habit, nor dismiss it because of a table that puts another runtime first. I would choose it when its compatibility, maturity, and operations fit the system’s needs. And I would try alternatives when there is a concrete reason to do so.

The right architecture decision is not the technology that wins an isolated test: it is the one that meets the requirements with a level of risk, cost, and complexity the team can sustain.

In this series

1. Node.js (this post)
2. Bun: is it really faster than Node.js?
3. Deno: security, TypeScript, and tooling
4. Final comparison: Node.js vs Bun vs Deno

Related reading

• Node.js vs Bun vs Deno: how to choose a runtime
• NestJS, Spring Boot, and FastAPI
• Benchmarks and architecture decisions
• Tool: which runtime suits you
• Tool: which frontend suits you
• Tool: which backend suits you
• Tool: which API protocol suits you

References

• Node.js — About
• Node.js — Release schedule
• Node.js — Previous releases
• Node.js — Event loop
• Node.js — Worker threads
• Node.js — TypeScript support
• Node.js — Profiling
• Node.js — Performance hooks
• Node.js — CLI
• Fastify — Benchmarks
• Fastify — Benchmarking guide

The figures cited are results published by the Fastify project in a specific configuration. They should be read as a framework-overhead reference, not as a direct prediction of a business API’s performance. For a valid comparison, fix versions, hardware, load, and configuration, repeat the measurements, and publish the code used.