We were considering RethinkDB for a mobile project, but ended up using Postgres on the backend and Realm in the apps with a custom REST API in between. This worked out really well for us, apart from all the work on implementing our own REST based sync (this was before Realm launched their backend product, which might have made a lot of that work unnecessary).
The reason we ended up with Postgres over RethinkDB was that our data model was very relationship heavy in ways that were easier to represent in a relational database than with RethinkDB's document model.
+1. To expand on my own post above - one of the biggest things that scares me away from NoSQL solutions, apart from the fact that the schema is not 'set in stone' and can be changed anytime by anyone, is the relationship aspect.
Because we build business and ERP extensions most of the time, the requirement for multiple joins across sometimes up to 7 or 8 tables was what I found difficult to manage in NoSQL data stores. Foreign keys, LEFT OUTER JOIN, SELECT DISTINCT, GROUP BY etc. are all second nature to me in SQL, but totally Greek to me in NoSQL.
RethinkDB has joins and I found its grouping to be straightforward and super powerful. Selecting distinct values is as simple as putting .distinct() at the end of your ReQL. While it doesn't have foreign keys, any value can act as one as long as it holds a tables primary key (or other indexed fields), in which case you can do db.table('other_table').get(primary_key_val) (or getAll(foregin_key_val, {index: 'my_index'}) if not the PK, but otherwise indexed).
Granted, it won't validate that the keys exist, however (since its schemaless at the DB level), so nothing will prevent you from inserting a document with foreign keys that are invalid, but from a querying point of view, foreign keys are easy. Would be nice if you could set insert/update-checked constraints though.
You absolutely can set the schema into stone, even when using a nosql database. That 'stone' is in your application code instead of the database though. And even when you use SQL the schema can be changed anytime (by anyone, in practice in most small companies). ALTER TABLE ...
I see your point, and we do tighten security on our database so that only certain users can perform ALTER, DROP etc. No doubt that can be done on NoSQL as well.
I guess I was talking about 'inadvertent' database changes. It seems that things like a simple typo can end up creating new attributes in a table when you didn't want it to, e.g. lets say earlier in my code, I have:
mytable.thisthing = 1
Then later on, someone mis-types:
mytable.thatthing = 2
I now have TWO attributes in my table instead of having the original "thisthing" attribute changed to 2.
An app with an SQL backend will usually throw an 'object/column not found' error if it recognises an attribute/column that is not on the original spec, but a couple of the NoSQL systems I've dealt with will happily take that line of code and work away with it, making debugging down the track a bit of a nightmare.
I am sure you can harden your NoSQL service to prevent this sort of thing, but then it becomes a question of whether the extra effort involved is worth it as compared to sticking with SQL where you are more constrained, but have better control over inadvertent table changes.
I once worked on a system which consisted of about a half-dozen services and MongoDB. At some point we noticed that a large percentage of the documents in a certain collection had somehow had a Date field coerced to String, which caused a bunch of stuff to not work correctly.
A simple typo in your SQL DDL statement can cause 'inadvertent' database changes.
Just like you have your SQL schema defined in a central place, allow only a few select developers to make changes to it, and put any changes under extra scrutiny, you do the same when the schema is defined in your application code.
'.. but what if typos' is not a valid argument. Not in 2016. You can use code reviews, tools (compilers, static type checkers) and good software engineering practices to avoid problems due to typos.
I must admit that I haven't delved deeply into Graph databases at this stage. If I can see a compelling reason that NoSQL/Graph will be a better/easier solution than pure SQL on a project, I am willing to, as an old dog, learn new tricks. ;)
The reason we ended up with Postgres over RethinkDB was that our data model was very relationship heavy in ways that were easier to represent in a relational database than with RethinkDB's document model.