Btw, we fixed some whitelist issues and if you want to play around with it, database creation should work now (if not with existing account you can create new one)
That type of tech + redis being quite bad implementation allows those gains (up to 2000%, we even have commands showing ~2200%, mostly lists since they have very cache unfriendly implementation)
We don't think it is needed. Currently, the only thing which is stopping it from running on bare-metal no hypervisor are some drivers for virtual devices (eg. virtio net driver).
Challenge is, ofc, supporting wide range of hardware options, but we don't intend to. We plan to support only modern x86_64 CPUs (arm is on the roadmap) and a select few NICs.
Current implementation is written to be hosted on public cloud, so we implement what is needed for that, but in the future we intend to allow self hosted version, but only on selected server hardware.
Now, if we have "big" server with like 256 cpus, etc. we can still split it many smaller "vms". Since the only code that runs with Hardware Manager is code we write, we can just add config options which pin execution to resources, eg. ram, we can just allow it to use from 4gb-8gb phys addr. Shared hardware like NIC is a bit trickier, but we do have some tricks up our sleeve which allow sharing.
Yes, since we never run untrusted code, there is no reason to use more complex mechanism. Memory is 1-1 mapped with physical ram. This also allows us to control cache even better (side note, we use huge 1gb pages for memory mapping, to ease pressure on TLB/MMU).
Btw, we fixed some whitelist issues and if you want to play around with it, database creation should work now (if not with existing account you can create new one)