Repository navigation
Investigating a Severe Performance Regression in Node.js v22 and v24 #60719
Description
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:
- Startup regression: nodejs/performance#180
- Module loading regression: nodejs/node#60397
- 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 benchmarkThe results have been consistent on both macOS ARM and Linux x64.
Questions for the Community
- Has anyone else encountered similar performance issues with v24?
- Are there any V8 flags or Node.js options that might help mitigate this?
- 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.
Activity
mcollina commentedon Nov 14, 2025
[-]Severe performance regression in Node.js v22 and v24 (57% slower on v24)[/-][+]Investigating a Severe Performance Regression in Node.js v22 and v24[/+]joyeecheung commentedon Nov 16, 2025
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 commentedon Nov 18, 2025
I've been able to reproduce this with the farmhash native module using its benchmark tests. The performance when transferring a JavaScript
Stringto a C++std::string(viaUtf8Value) 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
Node.js v24.11.1
The hash32 functions return a
Number, the hash64 functions return aBigIntand seed is aNumber. The.nodebinary was compiled once against Node-API v9 and used with both versions of Node.js.joyeecheung commentedon Nov 20, 2025
I suspect you are looking at the regression fixed by https://chromium-review.googlesource.com/c/v8/v8/+/7124103
jasnell commentedon Nov 20, 2025
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 commentedon Nov 20, 2025
Brilliant, thank you very much.
Dhruv-Garg79 commentedon Dec 1, 2025
Will this fix land in v24?
liamjay commentedon Dec 18, 2025
Will this be fixed by the EOL of Node.js v20?
chore: remove end-of-life nodejs versions and add active lts
Dhruv-Garg79 commentedon Feb 12, 2026
@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 commentedon Feb 12, 2026
For V8 cherry-picks: https://github.com/nodejs/node/blob/main/doc/contributing/maintaining/maintaining-V8.md
Dhruv-Garg79 commentedon Feb 13, 2026
@richardlau I have added the PR - #61798
Let me know if I need to change anything (I took reference from other v8 backport PRs for naming/messages).
Edit:
I ran the same benchmarks as mentioned by @lovell using local build of my branch
compared to v22.21.1
compared to v24.12.0
It's much better than v24.12.0, but still slower compared to v22.21.1
targos commentedon Feb 13, 2026
#61712 landed on
mainand will make its way into releases.ChALkeR commentedon Feb 15, 2026
@Dhruv-Garg79 how is v24.13.1?
Dhruv-Garg79 commentedon Feb 16, 2026
@ChALkeR it's almost same as v24.12.0.
v24.13.1
github-actions commentedon Jul 20, 2026
This issue has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
lovell commentedon Jul 20, 2026
I retested and can confirm JS to C++ string conversion is ~2x faster using Node.js 26 compared with Node.js 22 (and therefore ~4x faster than Node.js 24).
24.18.0
26.5.0
Thanks everyone for investigating/fixing/improving.