We're currently winding down on release 1.5 which will include Secondary Indexes. After that the next release will be all about being production ready and having better performance. We're hoping to have that out 3-4 months from now. We'll be posting updates about the process via github twitter and our blog.
If you're using C#, I'd recommend RavenDB.
Also not sure why relational == Meh.
RthinkDB does sound promising though not ready for primetime. The following (critical) features are still in the development pipeline: Secondary indices, a db backup tool.
Secondary index support is ready to go, we'll be releasing v1.5 with it in a few days.
2. Relational == Meh? Please elaborate, we're all waiting.
That's why there's a whole bunch of ORMs, with varying degrees of magic. It's also the reason some people were crazy enough to use relational DBs for key-value storage (eg. Reddit).
Please try and give reasons rather than restating the assertion.
The points in the blog post apply to most non-relational databases.
I have no doubt that document stores save you a bit of time in the early stages of a system. Not sure if I'd trust them to be reliable in the long run as your application-stored schema changes over time, though.
Our query language (ReQL) does support a lot of SQL-like queries, such as group-by and JOINs, but there are no relations defined.
It's also worth noting that a great team has sprung up to build a C# / .NET driver for RethinkDB (https://github.com/mfenniak/rethinkdb-net).
That's good to know, I'd like to give it a try, but only OS X and Linux seems to be supported.
I built a tool to track rankings for part of Reed Elsevier and I used mogodb but in a hybrid form using mysql db for the fixed stuff and mongodb for the representation of the first 120 results for a given language,engine,locale tripple
I would give anything to get back the time I spent developing my app using Raven and develop it with SQLServer instead. Ironically I feel so trapped by the schemalessness now that there is a not insignificant amount of data to port if I do need to make a significant schema change.
DO NOT FEAR THE JOINS!