In short, I definitely still want and need a BigMap.
Speaking from a Motoko developer’s POV, the status quo is insufficient for a variety of reasons:
-
Stable variables are the easiest way to persist data across canister upgrades. Currently, stable variables are limited by the size of the canister heap instead of the size of stable memory, because Motoko needs to serialize and deserialize the stable memory data in the heap. That is currently 4 GB, and in practice, the available heap is lower due to GC constraints (which are in the process of being lifted). 4 GB is not a lot of space.
-
To access the full 8 GB of stable memory, a developer can use the ExperimentalStableMemory library. However, it is very cumbersome to program with that right now, as you can’t use any of the off-the-shelf Motoko standard library data structures (like Trie) if you go that route. Also, that library is marked as experimental and may change at any time, which makes it unsuitable for production.
-
Applications that store images or video will very quickly hit the 4 or 8 GB limit. There was talk about specialized storage subnets, but there have been no updates on that front. I anticipate many may plan on using a BigMap as a blob store for large assets like video; that may have unintended implications if not carefully designed.
For me, I am building a consumer-facing dapp intended for a mass market. I worry a lot about hitting memory limits. I currently use Motoko standard library data structures (like Trie, RBTree, List) in a single canister, but that won’t nearly be enough. A database (or blob store) solution would be huge. In fact, the vision of BigMap is one of the more compelling sells of the IC developer ecosystem.
It wouldn’t necessary lower the bar for new developers trying to prototype something on the IC, but it will massively lower the bar for more experienced developers trying to build a scalable, productionized web3 dapp on the IC.