Trench benchmark: evaluating elixir/beam and Bun against Node.js in production on Linux Mint

Trench Benchmark: Evaluating Elixir/BEAM and Bun against Node.js in Production on Linux Mint#

The technology market experiences frequent cycles promoting new runtimes under the promise of low latency and unlimited concurrency. In high-availability corporate environments, maintaining a stable infrastructure requires rigorous validation. The operational stack is based on a consolidated setup: Node.js, pnpm, Prisma ORM, and PostgreSQL instances. However, the maturity of Elixir (Phoenix) and the execution efficiency brought by Bun motivated a comprehensive performance and technical compatibility audit.

This analysis documents a structured comparison between these runtimes, detailing their execution models, network architecture, security, observability, and performance metrics under Linux Mint operating systems.

1. The viability of transitioning from Node.js#

The decision to move away from a widely adopted ecosystem like Node.js is not just about raw processing speed. It involves maintenance costs, team training, and code rewrite effort. While the JavaScript ecosystem has the largest base of developers and libraries in the world, chronic issues related to high-scale memory consumption and event loop blocking prompt architects to evaluate alternatives like the Erlang Virtual Machine (BEAM) or Bun's optimized runtime.

2. Concurrency scope: the erlang virtual machine (BEAM)#

The Elixir ecosystem relies on the robustness of the BEAM (Erlang Virtual Machine), which manages execution through the Actor Model. Instead of heavy operating system threads, the BEAM manages Erlang processes that are extremely lightweight, consuming about 1 KB to 2 KB of memory each at creation time.

In practical terms, instead of handling concurrency by sharing memory (which requires complex locks and exposes the system to race conditions), Erlang processes communicate exclusively via asynchronous message passing. Fault tolerance is structured according to the let it crash philosophy:

• The programmer does not try to defensively catch every possible exception;
• Each isolated process performs its task, and if a critical error occurs, it simply crashes;
• A Supervisor process monitors the supervision tree (Supervision Tree) and restarts the child process using predefined strategies (such as one_for_one or one_for_all).

This ensures that an error in an isolated request does not affect the global stability of the server runtime.

3. Phoenix liveview and the state-of-the-art flow#

Phoenix LiveView changes the traditional web development paradigm by unifying state control on the server and transmitting dynamic updates to the browser over persistent WebSocket connections.

• Instead of loading large Single Page Application (SPA) libraries on the client, the server sends only a basic initial HTML payload;
• Once the WebSocket connection is established, any state change on the backend computes the template difference and sends back only small string fragments (HTML diffs) to the browser;
• The client, using a lightweight native JavaScript library, renders the changes in the DOM tree.

Operational trade-offs: While this approach eliminates the complexity of building large bundles on the client, it transfers the processing and memory persistence load to the server. Each active WebSocket connection maintains a stateful process in memory on the BEAM, requiring higher RAM provisioning in scenarios with millions of concurrent connections.

4. The cost of architectural debt in refactoring#

Migrating from a Node.js-based system to Elixir imposes a shift in computing paradigms. Moving from an imperative or object-oriented model to pure functional programming requires rewriting the entire codebase.

• Traditional JavaScript iteration structures, such as for and while loops, do not exist in Elixir;
• Iterating over datasets is mandatory via recursive calls or utilizing helper map and reduce functions from the Enum module (such as Enum.map/2 or Enum.reduce/3);
• Data is strictly immutable, meaning any modification generates a new structure in memory, requiring attention to the garbage collector (Garbage Collector) under high traffic.

5. Ecto vs. prisma and dependency management#

The data access and persistence layer also differs radically between the stacks:

• Prisma operates as a classic declarative ORM (Object-Relational Mapping) in the Node/Bun ecosystem, using engines compiled in Rust to execute queries;
• Ecto in Elixir does not follow the Active Record pattern. It acts as a database wrapper and schema mapper. Data mutations are managed by Changesets (which validate and cast data before sending it to the database), decoupling the table representation from write transactions.

In dependency management, while pnpm in the JavaScript ecosystem accelerates installations using a centralized content-addressable store and creating hard links/symlinks under the node_modules/ directory, Mix (Elixir's build tool) manages dependencies natively through the Hex repository, downloading and compiling isolated packages directly into the project's dependency folder deps/ without using symlinks.

6. Migration strategy: the strangler fig pattern#

Replacing an active legacy Node.js monolith all at once is financially unviable and introduces severe risks of business interruption. The recommended technical approach to mitigate this risk is applying the Strangler Fig pattern:

By isolating routes and services behind an API Gateway (such as Nginx or HAProxy), legacy Node.js APIs continue to process default requests while new critical routes or high-concurrency connections based on WebSockets are incrementally built in Elixir.

7. Node.js execution model: event loop and concurrency#

The Node.js concurrency model is based on the Event Loop executed on a single main thread (Single-Threaded for JavaScript code execution). However, the statement that Node.js is entirely single-threaded is conceptually incomplete.

• Node.js uses the C/C++ library libuv to manage asynchronous operating system operations;
• libuv manages an operating system thread pool (Thread Pool) configured by default to 4 parallel threads;
• Heavy operations like file system access (I/O), cryptography (Crypto), and compression (Zlib) are delegated to the Thread Pool, while the main JavaScript thread remains free to process the event loop.

If the main JavaScript thread executes a blocking CPU-heavy task, the Event Loop will freeze, resulting in latency and timeouts for active HTTP connections.

8. Bun's acceleration and the javascriptcore engine#

Unlike Node.js and Deno, which use Google's V8 engine, Bun was developed using WebKit's JavaScriptCore (JSC) engine, maintained by Apple.

• JavaScriptCore was designed for fast startup times and a smaller physical RAM footprint;
• It features three distinct JIT (Just-In-Time) optimizers and handles primitive data types differently than V8;
• The Bun runtime is written in the Zig programming language, allowing granular control over stack allocation and low-level system calls.

Bun's compatibility with legacy ecosystems has been enhanced, resolving past bugs with the Prisma Query Engine on local file systems.

9. The role of io_uring in Linux performance#

One of Bun's key performance advantages on Linux platforms is native support for io_uring, a modern asynchronous Linux Kernel subsystem introduced in version 5.1.

• Traditionally, asynchronous file operations in Linux rely on blocking system calls delegated to auxiliary threads (as in libuv);
• With io_uring, the application submits read and write requests directly to buffer queues mapped in shared memory with the Linux Kernel (Submission Queue and Completion Queue);
• This eliminates overhead generated by context switches and repetitive system calls (syscalls) per connection, allowing a single thread to execute thousands of socket reads without blocking the host CPU.

Note that modern versions of Node.js's libuv also optionally support enabling io_uring on compatible Linux environments.

10. The relevance of the operating system platform#

Running benchmarks on the Linux Mint operating system (a stable distribution based on the Ubuntu/Debian ecosystem) provides a highly consistent environment for evaluating runtimes. Metrics collected on Mint are directly equivalent to production servers running Ubuntu LTS. To guarantee technical accuracy, kernel configurations (such as the maximum number of open socket file descriptors) must be optimized by editing directives in the system configuration file /etc/security/limits.conf:

# Example of system limits hardening in /etc/security/limits.conf
* soft nofile 65536
* hard nofile 65536

11. Production benchmark methodology#

The methodology used in the Trench Benchmark followed strict software engineering parameters to ensure results reproducibility:

• Host Hardware: AMD Ryzen 7 5800X Processor (8 Cores, 16 Threads), 32 GB DDR4 RAM, Samsung 980 Pro NVMe SSD;
• Operating System: Linux Mint 22 (LTS Kernel 6.8.0);
• Tested Runtimes: Node.js v22.2.0, Bun v1.1.8, Elixir v1.17.0 (OTP 27, Phoenix v1.7.12);
• Load Tool: wrk2 executed from an auxiliary machine connected via a dedicated Gigabit local network, preventing load generation from competing for resources with the server;
• Test Scenarios:
• Scenario A: Simple REST endpoint returning a JSON-serialized object;
• Scenario B: Sequential SQL query (Read) in a PostgreSQL database via each ORM/Query wrapper (Prisma in Node/Bun, Ecto in Phoenix).
• Test Duration: 5 minutes of continuous stress after a 30-second warm-up period.

12. Results and quantitative metrics#

The raw metrics consolidated during the stress testing under concurrent load of 1,000 virtual clients revealed the following performance patterns:

Comparative performance table#

Cold start time (measured as the time elapsed between binary execution and the ability to respond to the first HTTP request) was evaluated to assess behavior in serverless topologies and elastic container scaling:

Cold Start Runtimes:
Node.js:  ████████████ 120ms
Bun:      █ 15ms
Elixir:   █████████████████████ 210ms

Analysis: Bun demonstrated the highest pure throughput for simple requests and the lowest startup time, benefiting from the JavaScriptCore engine. Conversely, Elixir presented the most stable and predictable p99 latency under extreme stress, proving that the BEAM's preemptive garbage collector mitigates cyclic latency spikes (Stop-The-World garbage collection) common in Node.js's V8.

13. Runtime security in Linux environments#

When operating Node.js, Bun, or BEAM environments in production, hardening the operating system is mandatory to mitigate process-level attack vectors.

Isolation and privilege guidelines#

1. Least Privilege: Never run mail services or application runtimes as the root user. Create a dedicated user with reduced shell privileges:

   # Create a user without administrative privileges
   useradd -M -s /usr/sbin/nologin app_runtime

1. Directory Hardening: Ensure that dependencies downloaded in the project root are not writable by the active application process.
2. Process Isolation: Use Linux Kernel namespaces (via Docker or Systemd Sandboxing) combined with restrictive Seccomp (Secure Computing Mode) profiles to prevent Bun (compiled in Zig) from executing unauthorized syscalls that could compromise host security.

14. Observability and SRE monitoring#

To gain visibility into the internal behavior of running applications, SRE teams must implement structured monitoring based on OpenTelemetry (OTel).

• Key Metrics: Track physical RAM consumption RSS (Resident Set Size), number of active WebSocket connections, and event loop latency;
• Elixir Observability: Use the native :telemetry library and Phoenix.LiveDashboard to inspect pending process queues and memory usage by individual actors in real time;
• Structured Logs: Configure runtimes to export transaction logs exclusively in JSON format to the system log (Journald or Syslog), facilitating automated parsing and alerts.

15. Version management with fnm and asdf#

In development environments on Linux Mint, installing global packages via sudo npm install -g pollutes the /usr/lib/ system directory and introduces security risks. A conservative approach suggests managing version tools in the user directory (User-Level).

To install and configure fnm (Fast Node Manager), a fast manager written in Rust, add the environment variables to your terminal profile files:

# Download and install fnm in the local user directory
curl -fsSL https://fnm.vercel.app/install | bash

After installation, configure the PATH by adding these lines to the end of your ~/.bashrc or ~/.zshrc file:

# Initialize fnm in the terminal
export PATH="$HOME/.local/share/fnm:$PATH"
eval "`fnm env`"

As an alternative for managing multiple stacks (managing Node, Elixir, Erlang, and Python in one tool), adopt asdf, or use dedicated managers like nvm or volta:

# Local initialization of plugins in asdf
source $HOME/.asdf/asdf.sh

16. Runtime decision matrix#

To select the best architecture based on project requirements, refer to the parameters defined in the comparative table below:

17. SRE checklist for stack migration assessment#

Before initiating a transition from Node.js to new stacks, validate the following phases:

• [ ] Migration Cost Audit: Map the estimated time required to rewrite imperative logic into functional patterns.
• [ ] Load Testing Methodology: Structure real-world test scenarios on Linux Mint using tools like wrk2.
• [ ] Linux Kernel Configurations: Ensure adequate open file limits (descriptors) in the configuration file /etc/security/limits.conf.
• [ ] Container Isolation: Design non-root Dockerfiles to run application binaries.
• [ ] System Call Hardening: Configure Seccomp rules to block unauthorized system calls to the Kernel.
• [ ] Log Collection Policies: Standardize logs in structured JSON format for continuous monitoring.
• [ ] API Gateway Configuration: Design reverse proxy and load balancing rules in the Nginx gateway.
• [ ] Memory Monitoring: Set up observability dashboards to track memory cache growth and WebSocket connections.
• [ ] Dependency Verification: Ensure clean local environments using FNM or ASDF without root privileges.
• [ ] Incremental Rollback Plan: Design an immediate rollback strategy on the API Gateway if the new microservice fails.

18. Operational risk assessment matrix#

See also

Development Turbopack Rust panic: dissecting and fixing inner_of_uppers_lost_follower in next.js 16

Development Runtime autopsy: fixing module not found .prisma/client and the prisma trap in next.js edge middleware

Development Isolated technical documentation portal in a next.js SaaS: nextra, prisma, and auth middleware without database pollution

This post is licensed under CC BY-NC.