Prisma Deploys Rust‑Rewritten Bun to Production, Fixing Memory Leaks and SQL Pool Hang

Bun's near‑million‑line Rust rewrite has moved beyond test pass rates; Prisma made a bold move by running the public beta of Prisma Compute on the Bun Rust canary build, not just in local trials or internal stress tests, but in real production workloads.

Two critical issues in stable Bun

In specific S3 read scenarios, the stable version continuously consumes memory until the process is OOM‑killed.

After a scale‑to‑zero resume, the stable SQL connection pool can become permanently stuck.

Both problems disappear when switching to the Rust rewrite.

Memory‑leak benchmark

Reproduction steps (run in a 1 GiB Linux container): repeatedly call Bun.S3File.arrayBuffer() on the same S3 object, then invoke Bun.gc(true) to force a full garbage collection.

With stable Bun 1.3.14+0d9b296af, RSS memory keeps rising, crossing 900 MiB after about 96 loops and eventually being killed by OOM. The JavaScript heap is cleared, yet the process memory grows, indicating a serious leak for long‑running services.

Using the Rust canary 1.3.14-canary.1+172afa532, the same script runs 4 096 loops without exceeding the threshold; the observed RSS peak is roughly 118 MiB and the memory curve stays flat.

This concrete comparison shows that the Rust version mitigates the leak far more effectively than any generic claim about Rust’s safety.

SQL connection‑pool deadlock after scale‑to‑zero

Prisma Compute supports scale‑to‑zero: instances pause when idle and resume on new traffic. During the pause, network connections may drop and idle database connections become invalid. The stable Bun SQL pool still counts these dead connections as available, causing new queries to wait forever without errors, auto‑reconnect, or crashes.

For services that rely on frequent pause‑resume cycles, this results in a product‑level failure: the first SQL query after wake‑up hangs indefinitely, rendering performance metrics meaningless.

Prisma reports that after switching to the Rust canary, this connection‑pool recovery issue no longer appears.

Prisma clarifies it does not claim the Rust version fixes every SQL‑pool problem, only that the specific fault they repeatedly observed is gone.

Why Prisma chose a canary for production

Typically production prefers stable releases, but Prisma faced three options:

Continue with the stable version, accepting the known memory leak and connection‑pool deadlock.

Maintain a private, patched Bun branch indefinitely.

Use the Rust canary that passes existing tests and feed production feedback upstream.

Prisma selected the third option. The decision was not based on a belief that “new code is inherently more reliable,” but on a pragmatic engineering judgment: a tested canary is safer than a stable version already proven to fail.

Because Prisma Compute is still in public beta, the team can iterate quickly, reproduce production failures in a minimal environment, submit them to Bun, verify fixes on the canary, and then redeploy.

This feedback loop is crucial for runtime projects: benchmarks show speed, test suites cover known behavior, but only real services expose the interaction of memory usage, connection pools, pause‑resume, and network anomalies.

Broader implications of AI‑generated Rust code

The Rust rewrite sparked controversy due to its rapid, near‑million‑line migration, much of it generated by Claude, raising concerns about code review depth. Downstream projects like yt‑dlp and Electrobun have already expressed hesitation.

Prisma’s production case provides concrete evidence that, at least for its workloads, the Rust version outperforms the stable build enough to change deployment decisions.

Nevertheless, a single production example cannot guarantee the rewrite is free of hidden risks. The code still contains unsafe blocks needing audit, AI‑translated patterns that are not idiomatic Rust, and broader platform and workload testing remains pending.

The key takeaway is how to assess AI‑generated infrastructure code: reproducibility, thorough testing, stable real‑world load behavior, and ongoing reviewer oversight are more reliable indicators than the model used or commit speed.

The Rust‑rewritten Bun now carries a substantial production‑grade scorecard, and the community awaits Bun author Jarred Sumner’s forthcoming blog detailing the rewrite’s audit process and risk mitigation strategy.