First, keep in mind I am not the OP.
Yes, dets is not appropriate as a storage engine here because it is unordered. It cannot serve range scans (regardless of how you encode the keys). I assume, as you say, that it’s temporary. I actually wrote a longer reply about why dets cannot be used for this case not long ago on another thread.
In FoundationDB the abstraction is an ordered binary/binary key/value store. Exposing this abstraction was an explicit design decision which they made very carefully.
Try to think about what this would actually mean in practice. Clients would have to somehow provide a comparison function all the way through the system to the underlying storage engine.
What would happen if different clients wanted to order data in different ways? How would you shard the keyspace in that case?
Instead, FDB offers a binary keyspace which is lexicographically encoded (sharded across many servers) and clients are required to encode their data in a way that it comes out sorted in a way that is useful. The tuple layer encodings are provided as a simple way to do that.
