Transaction size and duration is limited to keep the latency and throughput of the system manageable under load, from my understanding. It makes sense to some d

Transaction size and duration is limited to keep the latency and throughput of the system manageable under load, from my understanding. It makes sense to some degree even with no background in the design; if you are serving X/rps with a latency of Y milliseconds, using Z resources, and you double Y, you now need to double your resources Z as well, to serve the same amount of clients. You always hit a cap somewhere, so if you want consistent throughput and latency, it's maybe not a bad tradeoff. mvsqlite fixes the transaction size through its own transaction layer, from my understanding; I don't know how that would impact performance. The 10kb/100Kb key value limit is probably not fixable in any way, but it's not really a huge problem as a user in practice for FDB because you can just shard the value across two keys in a consistent transaction and it's fine. 10 kilobyte keys have pretty much never ever been an issue in my cases either; you can typically just do something like hash a really big key before insert and use that.