Those first two are pretty trivial. Keys are already stored in sorted order in a b-tree. Secondary indexing involves putting the indexed value to the left of the primary key in the key you write.

> Keys are already stored in sorted order in a b-tree

I thought FoundationDB stored data in a hash table. Didn't realize it uses a b-tree. Thanks for the clarification.

> Secondary indexing involves putting the indexed value to the left of the primary key in the key you write

By secondary index I meant having a sort order that's different from the primary key sort order.

FoundationDB provides the building blocks. Secondary indexes can be built on top of the regular primary index. Transactions make it possible to maintain a consistent 2I using a K/V interface.