Recall that there are built-in indices in Datastore on every property of every entity. This only applies to individual properties, but there are also composite indices. These allow the indexing of multiple property values all at once. If you are absolutely certain that a property will never be queried, you can explicitly exclude it from full indexing, which might give you some performance benefits, particularly in write operations where you don't want to be updating unnecessary indices.

The way Datastore works, every query will be evaluated using something known as its perfect index. The perfect index is an interesting concept. Given a query, the perfect index is that index which will most optimally return the query's results. The perfect index is evaluated based on the following conditions:

• If there is an equality filtering condition, that will be treated as the perfect index
• If there are inequality filters on columns, they will be used provided there is only one and no equality filter
• If there is neither an equality filter nor an inequality filter but a sort condition, the index on whatever property it is that is being sorted will be used for the perfect index.

Thus, the perfect index will be the equality filter, which means optimization of the needle-in-a-haystack type use cases. If there is no equality filter, then there can be at most one inequality filter which makes a range query. If neither inequality nor equality filters apply, then the sort order will be considered.

Full indexing is a wonderful feature of Datastore but it also has some important implications which we need to grasp. The first of these is that updates are really slow but lookups become blazingly fast. Another implication of full indexing is that joins are not supported. This is another similarity with Bigtable and another difference from relational databases. In addition, it is not possible to filter results based on subquery results and more than one inequality filter isn't acceptable.