where the function maps the documents into one out of 32 groups (so that's less than your 94, but shouldn't make a giant difference... I just had this database around). Did that on both 1 million and a 25 million document table, and memory usage looked fine and very stable.
This was on RethinkDB 2.0, and I might retry that on 1.16 later to see if I can reproduce it there.
Do you remember if you had set an explicit cache size back when you were testing RethinkDB?
Cool. Well, the process eventually crashed if I used the defaults. I had to give it a 6GB cache (I think, maybe it was more) for it to return anything. The process would actually allocate that much, too, so it's clear that it was effectively loading everything into memory.
Do you remember if you had set an explicit cache size back when you were testing RethinkDB?