The key-value storage limit should be something like 25MB. That’s what Cloudflare Workers KV offers: KV · Cloudflare Workers docs
You wouldn’t believe the amount of time I’ve wasted coding and testing helper functions to save/retrieve 32KB data chunks across multiple entity properties (Connect) and storage (Forge).
Increasing the limit to 128KB doesn’t make much difference. Developers will still need to go through that painful hack for certain types of applications.
Try build something like a survey app where you need to save/retrieve potentially hundreds of responses. You’ll quickly hit the 128KB key-value limit and thus need to split the data across multiple KVs.
An alternative I’d suggest to the Forge team is to build a looper function into the API so developers don’t need to worry about the KV limit, only the overall storage limit. ie they could just call storage.set() or storage.get() on megabytes of data and the API would manage splitting/retrieving it server-side.
eg this is how my keys end up looking:
- ${app}:responses:${macroId}:0
- ${app}:responses:${macroId}:1
- ${app}:responses:${macroId}:2
But I need to take the large data array, split it into max 128KB chunks, and save each KV. Then if data has been removed I either need to delete all the KVs and start fresh or overwrite each KV and then delete any remaining.
Then when I retrieve these KVs I need to loop through each one and stop when it hits an empty or undefined key.
You can see how it’s not fun to build for the first time.
If you guys dogfooded your dev platforms (Connect or Forge) you’d have picked up on this a long time ago. Hell, you make it so unnecessarily hard to keep data within the customer’s instance that for many of my Connect apps I resorted to saving compressed JSON data inside Confluence content attachments. As a result most developers on Connect simply resort to storing data in external databases, which is obviously a security issue. I can see the same situation playing out on Forge.