I would have used CockroachDB, it has all the requirements listed and you don't need to know in advance the queries you will perform when deciding the database schema.
If you use a compiler do not ignor ever ever the warning messages. Aim, from day 1 to have a compilation warning free. Write code to be read by humans, and do not ignore writing testing code, more or less you should have twice code in testing than real code under test.
They haven't any custom driver, CRDB is binary compatible with postgresql drivers, are marked as beta because "maybe" there is feature they haven't implemented. So far using pqxx (C++ driver) I haven't seen any issue.
In postgres you can choose if the replication is synchronous or asynchronous. For cascade replication (a slave uses as a master for another slave) the replica is always async.
well the demo then is broken indeed it shows still an "a" inside the multiset. Having say that I would never use a cuckoo in a multiset, indeed it becomes a bounded multiset. Also about the K-hashing for a bloom filter is not exact. You just need need a K-bit hashing function. If the goal is to support deletion then I would go for a Counting
Bloom filter
That's not the point. Trying to squeeze the code in less lines as much possible is not the way to go if you loose clarity.
Python coders keep repeting the mantra "less line of code" but in the mean time they keep typing: self. self. self.