FYI, with MongoDB, just because you can't and shouldn't index everything, doesn't mean you can't have any indexes... if your most common fields bring your queries down, they're still pretty helpful.
I actually really like where RethinkDB is headed, and within the year most of my issues should be resolved.
Another couple databases to consider, depending on your needs would be ElasticSearch and Cassandra... it reallly depends on your use case.
I'm not involved with RethinkDB but I lurk on their github issues and I'm pretty confident that automagic failover is dependent on them getting (their own implementation of) Raft integrated with everything. Looks like its getting close as a whole slew of issues were opened just the other day relating to Raft work.
We do not plan to implement secondary unique indexes. The philosophy behind RethinkDB is that if a feature cannot be efficiently scaled across multiple nodes we don't add it, and unfortunately unique secondary indexes are one such feature.
AFAIK most NoSQL databases don't implement it, and a few that do take two approaches -- forbid it on multiple shards, or just take a massive performance hit during sharding.
We chose to keep the feature out of the database. This way the application can be architected to account for it, so it remains fast as the database scales up.
This is good, for what it's worth. Having different feature sets for sharded vs unsharded is just utterly confusing, and something MongoDB got really wrong.
We had a similar issue with queries that didn't match an index... later pages would time out, etc... we limited our results for that class of queries... The next generation will use cassandra with some custom searching/caching... that will work a bit differently.
I actually really like where RethinkDB is headed, and within the year most of my issues should be resolved.
Another couple databases to consider, depending on your needs would be ElasticSearch and Cassandra... it reallly depends on your use case.