Thank you for your effort, but I don’t think that’s good news. That would mean that any subnet handling more than, say, 100 - 200 transactions per second would no longer be usable for update calls without paying for compute allocation ? And compute allocation could be very expensive for the developer and is also a bit unfaire , because it depends only of the subnet.
In general switching a project to another subnet is also not very easy with all the data. Is there a way to switch the subnet in an easy way with the data stored on the canister ?
I don’t want to imagine what it would mean if the IC gets even more usage than it does now. Hopping and switching the subnet will be a common task.
Have we reached here a dangerous limitation of the IC ?
In my case it is all about GDPR complaint applications. I would like to link the following post and articles about GDPR and ask how it aligns with the current situation:
Don’t get me wrong, but as of now, you can’t practically say that the IC is GDPR compliant if you have to rely on additional compute allocation due to the costs. A 1% allocation will cost approximately $35 per month.
My hope is, there will be a better solution than those you have mentioned.