A database is going to do a query like that in one of two ways: scan over (all of|a column family of) the data, or look in some kind of index on "someproperty".

A database is going to do a query like that in one of two ways: scan over (all of|a column family of) the data, or look in some kind of index on "someproperty". In our approach this kind of functionality is the responsibility of a higher "layer" of the system above our key/value API. There are lots of ways of organizing and indexing data with different tradeoffs between search and update performance for different kinds of queries. We support pretty much all of them-- not by building any of them into the core, but by providing a general transaction facility that permits arbitrary indices to be updated. For example: in a database like Mongo, queries like that one don't scale linearly even if there is an index, because you have to ask every shard to look in its local index. In FoundationDB, you would store the index in the database as keys like (someproperty_index, "123", _id) and an index read would only need to go to a single server. It can be a hassle to create all the higher level functionality yourself, though! Over time, we and others will be offering more "opinionated" layers to save you time.