The 2GB limit is due to the default, semi-space, copying garbage collector, which roughly requires twice the heap space to perform GC, but conveniently leaves the second half available for stable variable serialization.
In moc 0.6.27, we’ve implemented streaming serialization of stable variables to stable memory, avoiding the need for all but a smallish buffer in wasm memory.
The hope is that streaming would allow people to more safely select the alternative mark-compact gc, which can utilize much more of wasm memory for the Motoko heap since it doesn’t require a separate semi-space (the other 2GB) to evacuate live data to.
However, expanding the usable heap does the raise the question whether a GC will be able to complete within a single message without exceeding the cycle budget.
I’m hoping the ongoing work on so-called Deterministic Time Slicing, which will allow a single (e.g. GC) message to span several rounds, and not be limited by a small cycle budget, will finally free us of these concerns.
For an app like encrypted notes, I think it would actually make sense to consider storing the encrypted data as blobs in stable memory, reducing the pressure on the GC and utilizing the currently up to 8GB of additional memory available as raw stable memory. But I don’t know the details of that particular app.