One feature that I'm waiting for with RethinkDB is unique indexing other than primary key. I frequently use unique indexes, and lacking that feature has been something that has deferred my interest in trying RethinkDB out.
Slava @ Rethink here. I'll open a github issue when I get to a computer (and will post it here). We'll see if it's technically feasible and how/when we can schedule it.
Have to agree with that. A very ugly workaround is something like:
r.branch(r.table("users").getAll(email, {index: "email"}).isEmpty(), r.table("users").insert(user), {})
This also holds us back from trying it out as our primary data store (but it is interesting as an additional store for other things that don't need additional unique keys)
Now this is a database whose every release brings something genuinely useful. I am really glad this exists and gives me a good measuring stick to compare to other db's.
I think it is getting there, people are moving away from MongoDB, towards Riak, but RethinkDB is so much more then Riak and I would rather use it. It is very convenient, it has a panel for trying out queries and monitoring db's, it is fairly easy to setup sync.
I didn't try some big instalation, and I would expect at least some issues, but generally, so far, sun is shining each time I use RethinkDB
I think the benefits in terms of programming are roughly the same... but in terms of infrastructure overhead, sane defaults and cost, there's quite a bit of difference.
Explicit control over write durability and out-dated reads alone is a pretty big advantage. When you start to factor in how much better ReQL is and the atomic nature of ReQL queries RethinkDB pulls far ahead.
This will probably not be a MongoDB killer. Check out http://www.amisalabs.com. That will have more potential but also probably won't be a Mongodb killer.
I never post on HN, but I will say I've been using RethinkDB for a couple of weeks now and it's fantastic, the Ruby drivers work great. It's a big change from writing sql for over 10 years, but the pros far out weigh the cons. Going to upgrade now. They are also very helpful in irc.
I am really interested in RethinkDB, and just wish I could convince myself to use it in an actual product. What's peoples' use case for the most part? I mean, I use PostgreSQL and MySQL for most of my applications, and Sqlite for smaller stuff. I've steered clear of the whole "NoSQL" movement up til this point, but Rethink seems to have the correct cross-section of a) features from SQL DB's that I use, and b) features from NoSQL-styled DB's that I want.
tl;dr -- Should I use Rethink as my primary data-store, considering that I don't use many advanced SQL features for the most part?
I'd say it's definitely a hybrid of the NoSQL movement and SQL. You have joins, data integrity (not giving a thumbs up "A+++++++ would write again" until data is on disk), and expressive queries. On the flip side, you have real document storage and querying abilities: you can query on subfields of subfields of etc. You can index arbitrary components of your documents. The best part is the auto-partitioning/replication.
As someone who's used it for over 6 months now (4 in production) can't say I've regretted the decision or ever looked back. Every time I've hit a bug or a problem, the Rethink team has stepped in to make it right, even to the point of patching the database for me personally when things got rough (index corruption) and helped me recover all my data into a new instance.
My advice: if you are happy with PostgreSQL, stay with it. It's not worth switching databases if you are happy just for the hell of it. But if you're looking to build a new app and need to scale the database to more than one master three slaves without the ops nightmares and you don't mind learning something new, definitely give Rethink a shot. The guys building it are really smart and the community around it is excellent (and growing steadily).
Since I almost never post to HN this must be the story to do so:
I have used rethinkDB in production since may (and obviously in dev - about since v 1.1). It's kick ass. The things you immediately fall in love with is the awesome admin dashboard, data explorer, and of course the very beautiful query language.
Full disclosure: I am not employed by RethinkDB, I am just a fanboy and user :)
@Slava and others. When it comes to database, you know, there is always a fear... A new company, young (extremely talented though) folks, etc.
You need to put out in the front page of your website use cases. Real world use cases where one can read testimonials and facts, regarding RethinkDB capability, readability and stability.
It will help people to make the step toward trying it, and if they'll try, and get satisfaction, they can end up using it in production.
I think Rethink is general enough that they don't need use-cases listed on the site. It's not an in-memory database geared towards real-time analytics, it's not a clustered map-reduce system for number crunching, it's a document-based database with real durability and a great query language. Use your imagination.
You're right though about the fear of putting your company's data into a new system. However, I think they've taken the right approach by warning people of the risks while at the same time working as hard as they can to mitigate any of the risks.
Getting people to trust you is a slow but steady process, and I think they're playing it right.
Is there any way to upgrade clusters without downtime? It seems the import/export requires a shutdown, and nodes running different versions cannot join the same cluster, correct?
Import/export don't require a shutdown, but upgrading does.
Like you said, you cannot connect two nodes with different versions for now.
The versions will eventually be backward compatible (probably as soon as we'll be production ready). But for now, you will have a downtime.
Sorry for that, we'll try to hit the production ready milestone as soon as possible.
Thanks for the response. Communication of the status of the releases was very clear, so we were aware that not everything is 100% production ready. At least it's good to know for sure that we have to plan for downtime when upgrading, and aren't simply missing some less obvious way.
A side effect of upgrading is that my write speeds jumped through the roof:
I went from ~6K writes/sec yesterday on my rMBP (SDD, 16GB RAM, 2.3GHz quad core) to ~13K/sec today:
http://i.imgur.com/ZXdFOnn.png (it fluctuate between 9K and 13K to bulk insert ~600K documents).
Congrats to the RethinkDB team!