This is a documentation issue. The 2GB limit is not for the Buffer, but rather an I/O limit.

@RedYetiDev @davazp can I update de documentation?

It would probably be good to always include the current limit in the error message.
We might want to look into the actual reason for the original limit. It could probably also be adjusted. I am therefore not convinced it's only about the documentation.

The reason is explained here: libuv/libuv#1501

I imagined it was something like that. On Linux it also seems that the read syscall is limited to 2GiB.

However that is pretty low level. Wouldn’t be better if readFile internally make multiple read calls and populate the buffer content and then return it?

Even if we do not want to allow arbitrarily large files, they would allow us to increase the limit to something a bit more forgiving.

handling multiple calls from the Node.js side SGTM.

To read large files in chunks (greater than 2 GiB) using Node.js, you can use fs.createReadStream() to handle the file in smaller, manageable chunks rather than loading the entire file into memory. This avoids hitting the 2 GiB limit that occurs when using fs.readFile(), as it loads the entire file into memory.

const fs = require('fs');

const filePath = 'path/to/large/file'; // Specify the path to your large file
const stream = fs.createReadStream(filePath, { highWaterMark: 64 * 1024 }); // 64 KB chunks

stream.on('data', (chunk) => {
console.log('Received chunk:', chunk);
// Process the chunk here
});

stream.on('end', () => {
console.log('Finished reading the file.');
});

stream.on('error', (err) => {
console.error('Error reading the file:', err);
});