Am I the only one that hardly ever needs a case-sensitive query/index on string data? This is the one feature I miss from the MySQL glory days. With postgres, I use the citext type (case-insensitive text) but I guess Mongo and ReThinkDB expect you to either store the data as all lower or upper, or duplicate the field (for indexing).
The reason we (and probably Mongo folks) do it this way is because JSON is case-sensitive, so making indexes case-insensitive wouldn't work very well.
EDIT: it looks like I misread your comment. I was talking about index/field names, while I think you were talking about field values. In this case Sam's comment below is correct -- once we add string.toLower() (which is very easy) you'll be able to do case-insensitive indexing if you like because the indexing system supports arbitrary reql expressions. If you're using rethink and this is important to you, let me (slava@rethinkdb.com) know, and we'll prioritize this.
Yes, indices are updated incrementally. You can currently only evaluate an index for a given row based only on that row, not on other rows. The reasons for this are pretty deep -- if you start evaluating indexes on a row based on other rows, the result becomes non-deterministic and can't easily be replicated across the cluster. Once we introduce value-based replication (as opposed to evaluation-based replication we have now) this will become possible.
Installed and played with (1.3 I think) and it looks very promising but the ability to query and order by case-insensitive text is a requirement for us. Our app deals with user provided names of people, places and things that are commonly searched and sorted.
So not using RethinkDB today, but I am 100% in love with what you guys are trying to accomplish.
If or once a string.toLower() function is added to RQL, you'll be able to have case-insensitive indexes in RethinkDB, because you can index on arbitrary functions of your rows.
