RethinkDB is awesome, but to my understanding it's one of the slowest document stores out there right now. That's one reason why it hasn't seen very widespread adoption yet. For smaller projects it's not a problem, but for large projects databases can often be a major bottleneck.

RethinkDB performance has improved dramatically in the last year. We'll be posting benchmarks for the 2.0 release, which should dispel any performance concerns.

That's great. I'd love to see you guys completely replace the MongoDBs of the world. Once you eventually reach MongoDB's performance across the important areas, switching would be a no brainer for me, and probably for many others.

Please just make sure that data safety in RethinkDB always takes precedence over performance.

The last thing we need is another MongoDB that can not be trusted with anything valuable.

RethinkDB CEO here. Don't worry. During early stages of ReQL design I suggested string representation for commands (that start with the dollar sign) and the engineering team kicked me out of the room because that would have opened RethinkDB up to injection attacks. If I suggest something like write durability off by default (or something of the sort) I'll have a full mutiny on my hands.

We're systems people. You won't get another Mongo.

MongoDB has been pretty decent (the defaults early on were probably not the best choices)...

The biggest difference in RethinkDB's approach has been data sanity first, niceties a close second (nice devops and dev interfaces)... It's a very well thought out database, and as long as people are moving a little farther away from SQL thinking and interfaces it makes more sense.

I'm not sure where automatic failover stands wrt RethinkDB, but barring that, I would probably reach for RethinkDB, MongoDB or ElasticSearch for most small-medium db tasks, depending on what the application's needs are. By medium I mean less than 10-15 server cluster. Anything bigger, Cassandra would probably be my first choice.

Try TokuMX (MongoDB on steroids with ACID transactions) http://www.tokutek.com/tokumx-for-mongodb/

You don't fix MongoDB and all its data destroying habits (as documented by aphyr and a dozen blog posts) by replacing the index.

It's rotten from the core, poorly designed on every layer, and has caused many companies great grief.

I wouldn't touch it or any of it's descendants with a 10 foot pole.

You should do more research on TokuMX. They didn't just replace index, they rewrote a lot of the core.

I feel these interfaces can be a bit of a crutch, I'd much rather have users interfacing with an API than manipulating the DB directly.

That's exactly why we added the administration api to our query language in this release. Previously we had some command line tools that were really a pain. Now you can start development using the webui, and then shift to scripting massive deployments once you get there

My thoughts precisely! I also love that official driver for js is a join to use, unlike mongodb...