Hi @Seb,
Thank you for reaching out:
- I believe we can make EOP stable around Q2. It should be pretty safe, however, there might still be a risk of hidden bugs (as usual with all software). We did extensive testing and until now, did not find any major bugs that caused data loss or corruption. Maybe the most relevant one is Security Fix in Motoko (dfx 0.24.3) that is fixed. My recommendation is that when you use EOP in beta (and actually also otherwise), that you have a possibility to back up/download the data just in case. Also, it is always good to do large-scaled scalability tests before deploying.
- Transitioning from non-EOP to EOP is seamless and happens automatically when adding the
--enhanced-orthogonal-persistencecompiler option and performing an upgrade. However, the reverse direction, downgrading from EOP to classical persistence is not supported. - One important thing to consider is the current memory capacity. EOP uses 64-bit main memory. However, due to technical aspects of the IC and general risk considerations for the Wasm64 rollout, the IC currently still only supports 4GB even for 64-bit. So, there may be a regression in the effective scale of the application (although in the past we only supported up to 2 GB of memory to be persisted). Of course, we plan to increase the capacity beyond 4GB, but I expect this happening also towards Q2, maybe growing first to 6/8 GB. So, this also means that testing scalability is very important. The good thing is that when the IC increases capacity, a Motoko EOP canister should be able to automatically scale to higher capacity without recompilation or need for upgrading (assuming there is no or a high enough “Wasm memory limit” configured for the canister).
Please let me know if I can provide more information or if you have more questions.
Best regards,
Luc