Their application is file systems and no file systems offer that capability. In order to provide transactionality for multi-file operations, you have to have a file that represents "the transaction" and move it or create/delete it.

In most file systems, you can't even update a file atomically, actually -- what you can update atomically is a disk page, 4-16k. Database servers might then maintain a separate, small file that contains only a transaction token, which is atomically updated to contain the last transaction written to disk in full.

I don't judge them, I was confused by the choice of systems to compare with and thought that I didn't understand article. I think that comparison with MongoDB or RethinkDB would be more appropriate in this case.

Keep in mind that the Bizur is being used for services internal to the file system. So the use case is more like etcd or ZooKeeper's, for example in one role it is a cluster configuration database (with high availablity, fault tolerance, consistency, etc.)

Yes, They guarantee consensus per key ( which is in this case per bucket as they aggregate them). You won't be able to have atomic operation across bucket neither you can have serialisation of transactions across bucket. It's a trade-off, my guess is that their use case does not require a consistent view of the overall k/v store.

Indeed, it is a tradeoff, and our solution doesn't require consistency across multiple keys.

More generally, any solution that doesn't require transactions across multiple keys, can use Bizur instead of classical Paxos, and achieve the same benefits (faster recovery from failures, higher concurrency, etc.)