My situation was very similar to latch's above. I vetted it earlier this year, after having developed warm fuzzy feelings for it last year at another company. We wound up going with Postgres + Solr because A) we've used them before, B) they performed a lot better than Rethink, and C) Rethink's compensating features (distribution) weren't worth the tradeoff.

I thought Rethink seemed like Mongo done right. Both have a simple document storage model. Rethink embraced "relations" a lot better, and seemed interested in borrowing some good ideas from relational theory. Having a uniform query language was a good idea; the "builder" style was an odd choice but whatever. Where Mongo ignored and failed to address Aphyr's concerns directly (and antirez seemed to emit a cloud of interminable semantics debates) Rethink actually reached out to Aphyr for testing and rapidly took action based on his recommendations. They accepted the criticism readily and went to some effort to be transparent about what they could and could not do. Failover was not a 1.0 feature, so they didn't hose it totally. The admin interface was beautiful. You really felt like you had a simple, powerful tool that you could understand.

Performance wasn't great. This was the showstopper for me. But to be honest, I probably wasn't going to give them a dollar even if it was a lot better. I'm not paying for Postgres or Solr either. I don't know how you bootstrap a database business. The Mongo/MySQL approach of "make garbage, monetize, hope someday you can refactor it into shape" looks obviously wrong stacked up against Postgres, which always took the academic approach of "first make it right, then make it perform." But performance is a feature and it takes a long time to make a database right, let alone perform. I think they took the right approach. It's just a long process, and it may not be compatible with startup culture.