Investigating a Severe Performance Regression in Node.js v22 and v24

[titanism]

Investigating a Severe Performance Regression in Node.js v22 and v24

Hello everyone,

We (@forwardemail) have been running some benchmarks with better-sqlite3-multiple-ciphers and came across what appears to be a significant performance regression in newer Node.js versions. I wanted to share my findings in case they are helpful to the community, especially for those who rely on native modules with SQLite. We use encrypted SQLite databases for storing folks email, see our write-up at https://forwardemail.net/en/blog/docs/best-quantum-safe-encrypted-email-service.

Summary of Findings

My benchmarks indicate that Node.js v24 is approximately 57% slower than v20 for SQLite SELECT operations, while Node.js v22 shows a smaller regression of about 7-9%. These findings suggest the performance issue may not be specific to better-sqlite3 but could be related to a broader change in the V8 engine that affects native modules.

Benchmark Results

I've created a benchmark suite to reproduce these results, which you can find here: https://github.com/forwardemail/sqlite-benchmarks

Here is a summary of the results I observed with better-sqlite3-multiple-ciphers:

Node.js Version	SELECT ops/sec	vs v20 LTS
v20.19.5 (LTS)	18,383	baseline
v22.21.1	~17,000	-7%
v24.11.1	~7,900	-57%

As the table shows, the performance on v24 is less than half of that on v20 for this specific database workload.

Potential Root Cause

After some investigation, I believe this regression may be linked to the V8 13.6 engine upgrade in Node.js v24. The V8 versions for each Node.js release are as follows:

• Node.js v20: V8 11.3 (Stable Performance)
• Node.js v22: V8 12.4 (Minor Regression)
• Node.js v24: V8 13.6 (Major Regression)

The most significant change in V8 13.6 appears to be the move to a V8-owned CppHeap (nodejs/node#52718), which alters how C++ objects are managed and garbage collected in native modules. While this change was intended to simplify the API, it seems to have had an unintended impact on the performance of native modules that frequently cross the JS/C++ boundary.

How This Might Affect SQLite Performance

The performance-critical paths in better-sqlite3 involve frequent C++ object allocation, heavy interaction between JS and C++, and string conversions. The new V8-owned CppHeap may have introduced different garbage collection timing, allocation patterns, or boundary-crossing overhead that could be contributing to this slowdown.

Related Upstream Issues

This issue may be part of a broader pattern of performance regressions in recent Node.js versions:

1. Startup regression: nodejs/performance#180
2. Module loading regression: nodejs/node#60397
3. CppHeap deprecation: nodejs/node#52718

These issues suggest that V8 11.3 (in Node.js v20) may have been a more optimized version for native module performance.

Suggestions for a Path Forward

I've put together some thoughts on how we might be able to approach this. I'm happy to help with any of these steps.

For Users Experiencing This Issue

For those affected by this performance regression, a possible short-term workaround could be to remain on Node.js v20 LTS. It appears to be the most stable and performant version for this workload and is supported until April 2026.

Potential Areas for Investigation

It seems the performance degradation might be linked to the CppHeap changes in V8. It could be beneficial for the V8 and Node.js teams to investigate this further. Some areas that might be worth exploring include:

• Benchmarking the CppHeap regression: A performance comparison of native modules before and after the CppHeap changes could help confirm the impact.
• Profiling hot paths: It might be useful to profile the following areas:
  • Object allocation in the V8-owned CppHeap
  • Garbage collection behavior for frequently created C++ objects
  • Overhead from JS/C++ boundary crossings
  • String encoding/decoding with WriteUtf8V2()

Possible Long-Term Solutions

If the regression in V8 cannot be addressed upstream, it might be necessary for native modules like better-sqlite3 to adapt. Some potential strategies could include:

• Object pooling: Reusing statement objects to reduce allocation overhead.
• Batch operations: Processing multiple rows at once to minimize boundary crossings.
• Optimized string handling: Caching string conversions or exploring alternative V8 APIs.
• Manual memory management: Taking more explicit control over the object lifecycle to mitigate GC issues.

However, it seems that addressing this at the V8 level would be the most effective solution, as it would benefit all native modules.

Reproduction

To reproduce the benchmark results, you can clone the repository and run the tests:

git clone https://github.com/forwardemail/sqlite-benchmarks.git
cd sqlite-benchmarks
npm install

# Test with different Node.js versions
nvm use 20 && npm run benchmark
nvm use 22 && npm run benchmark
nvm use 24 && npm run benchmark

The results have been consistent on both macOS ARM and Linux x64.

Questions for the Community

1. Has anyone else encountered similar performance issues with v24?
2. Are there any V8 flags or Node.js options that might help mitigate this?
3. Would it be appropriate to escalate this to the V8 team for their input?

I am more than willing to assist with further profiling, testing, or providing any additional information that might be helpful. Thank you for your time and consideration.

[mcollina]

@titanism I don’t mind this being AI written. I mind it assigning tasks to us. This is an organization based on volunteers, and it’s written pretending work to be done “what needs to happen”. Please check your AI-written content before posting, as you are responsible for it anyway. Please amend it and make recommendations, not demands.

If this is relevant for some production workload, then the company profiting off it is welcome to help and contribute a fix, sponsor a collaborator to help, hire a collaborator or a company to fix this.

[joyeecheung]

I think it’s unlikely to be related to CppHeap, because currently CppHeap in Node.js is mostly only used for script compilation; unless the application is heavy on compiling scripts, which seems unlikely judging from the name of the application, it’s likely something else.

[lovell]

I've been able to reproduce this with the farmhash native module using its benchmark tests. The performance when transferring a JavaScript String to a C++ std::string (via Utf8Value) has approximately halved between v22.21.1 and v24.11.1. Hopefully this information can help someone narrow down possible underlying changes/causes.

Node.js v22.21.1

Using key of length 10000
farmhash-hash32-string x 335,871 ops/sec ±0.93% (92 runs sampled)
farmhash-hash32-buffer x 723,035 ops/sec ±0.49% (99 runs sampled)
farmhash-hash32+seed-string x 335,389 ops/sec ±0.84% (91 runs sampled)
farmhash-hash32+seed-buffer x 678,827 ops/sec ±1.13% (89 runs sampled)
farmhash-hash64-string x 593,499 ops/sec ±0.98% (99 runs sampled)
farmhash-hash64-buffer x 2,123,900 ops/sec ±0.85% (92 runs sampled)
farmhash-hash64+seed-string x 522,131 ops/sec ±0.38% (96 runs sampled)
farmhash-hash64+seed-buffer x 1,784,170 ops/sec ±0.31% (93 runs sampled)
farmhash-hash64+seeds-string x 517,844 ops/sec ±0.52% (100 runs sampled)
farmhash-hash64+seeds-buffer x 1,746,578 ops/sec ±0.60% (93 runs sampled)

Node.js v24.11.1

Using key of length 10000
farmhash-hash32-string x 160,187 ops/sec ±1.93% (94 runs sampled)
farmhash-hash32-buffer x 725,678 ops/sec ±1.21% (97 runs sampled)
farmhash-hash32+seed-string x 165,089 ops/sec ±0.44% (95 runs sampled)
farmhash-hash32+seed-buffer x 723,313 ops/sec ±0.21% (100 runs sampled)
farmhash-hash64-string x 195,270 ops/sec ±0.44% (94 runs sampled)
farmhash-hash64-buffer x 2,176,829 ops/sec ±0.20% (94 runs sampled)
farmhash-hash64+seed-string x 194,099 ops/sec ±0.18% (102 runs sampled)
farmhash-hash64+seed-buffer x 1,798,656 ops/sec ±0.19% (95 runs sampled)
farmhash-hash64+seeds-string x 193,943 ops/sec ±0.30% (102 runs sampled)
farmhash-hash64+seeds-buffer x 1,762,318 ops/sec ±0.60% (96 runs sampled)

The hash32 functions return a Number, the hash64 functions return a BigInt and seed is a Number. The .node binary was compiled once against Node-API v9 and used with both versions of Node.js.

[joyeecheung]

I suspect you are looking at the regression fixed by https://chromium-review.googlesource.com/c/v8/v8/+/7124103

[jasnell]

Agree with @joyeecheung ... even the differences in the benchmark numbers there align with what we were seeing in that regression. The regression has been fixed upstream and other improvements are being made. We'll pick it up either when v8 is updated to a version including that patch or when someone cherry picks it in.

[lovell]

Brilliant, thank you very much.

[Dhruv-Garg79]

Will this fix land in v24?

[liamjay]

Will this be fixed by the EOL of Node.js v20?

[Dhruv-Garg79]

@jasnell I think the fix has already been merged upstream, but v24 will not update to a new v8 version.
So the only choice is to cherry-pick this change, right? I can try doing that. I have gone through the contributing.md, is there anything else I should keep in mind?

[richardlau]

@jasnell I think the fix has already been merged upstream, but v24 will not update to a new v8 version. So the only choice is to cherry-pick this change, right? I can try doing that. I have gone through the contributing.md, is there anything else I should keep in mind?

For V8 cherry-picks: https://github.com/nodejs/node/blob/main/doc/contributing/maintaining/maintaining-V8.md