Hey John Hardy thanks for the question,
Scaling made easy - you can shard and replicate in a couple clicks with their a web ui.
Allows you to rapidly iterate and evolve your data structure over time. Let’s you focus on your application and prototyping over data modeling
It is both developer and operations oriented - combining an easy-to-use powerful query language with simple controls for operating at scale with high availability
Comes with a fantastic GUI based tool for real-time performance and health status. It’s also a management tool for each server and database in your cluster, as well as a data explorer for running queries
The creation of a table in SQL and RethinkDB brings forward the issue of requiring a schema. In the world of RethinkDB you need not concern yourself with confirming the structure of your data prior to creating a table, only knowing that you want to store a certain type of something. > In SQL however, data modelling has to be considered as a step prior to creating your tables. This is important to flag up as in agile development, SQL puts up a significant road-block here. There is certain commitment that needs to be made by the developer up-front in order to cement the schema of a database. So if you’re in a situation where you have a fair amount of uncertainty in how you will model your data, RethinkDB has a clear advantage here
(Insertion) RethinkDB works with, and stores documents as JSON. You can use the insert command to insert one or more records at a time, and each document can have a varying structure and also contain nested documents. Any valid JSON document, is valid in RethinkDB
(Querying) When looking at equality, there isn’t too much to differentiate NoSQL and Rethink
**Below is the SQL counterpart**
WHERE name = 'Goku';
When looking outside of equality, in RethinkDB you can use functions as filters for your data
In rethink grouping is also significantly easier, for example to group characters in the database by species we can apply a group by species
To achieve a similar result in SQL requires the use of LEFT JOINs, plus the use of group_concat() to make sure information isn’t lost from grouping.
RethinkDB shines in realtime applications (think google docs live editing with multiple people), right now they have streams but you still have to do a decent amount of work yourself to make it happen. However they have a feature coming up very soon which abstracts away complexity involved with setting up Socket.io/WebWorkers so very soon it should be much easier to set up realtime functionality
Although as you can tell I’m a fan, I’m not saying RethinkDB is the perfect solution for every problem, for example it is not a good solution if you need a fixed schema, or require transaction support. In this case you should still look to SQL for these use cases. It is also not a good solution if you intend to use it for intense data analysis. This use case would be better suited to another NoSQL system like Hadoop.
Robert Lancer is our tech lead and architect, and as you may guess is also a big fan of RethinkDB, if you have any questions about the stack or RethinkDB in particular, feel free to post a question on his wall or reach out to me whenever. There, that’s the end of my pitch on Rethink, hope you enjoyed it haha 😃