As most of the time, each tool for each job... Structure a production application at corporate level with SQL and store any document-like resource with NoSQL.
Relationship are complex, don't break up! Hehe!
The choice of database for production level projects is a critical decision that we need to make at the initial stages of the project. Most of us do the mistake of choosing databases by simply going through the features list,popularity,official docs and couple of benchmarking results on random sites without giving much thought to choosing database based on the problem we are actually trying to solve or the type of projects we are undertaking in future. Matter of fact is one needs to do proper benchmarking and load/stress testing before picking up dbs, go through docn and understand whether available schema design and queries are suitable for one's project. We too made the mistake of choosing couchbase in production once eventually realizing that it was not suitable for our requirements and switched to redis eventually at the time when our applications were in production. This kind of migrations do take a lot of time and efforts but sometimes are inevitable to tackle performance issues. I completely agree that sometimes sql databases are just good enough and provide proper structure to database schema design and might be suitable rather than trying to bother about faster read times :D
Thats why we examined the alternatives like Arangodb or Couchbase.
We used Arangodb in production, but the problem is that, the TECH is not as mature and as stable as an old school giant like mysql or postgre.
We hit stability issues from time to time, and we happen to report bugs.
Sometimes my nightmare is that, I ask, what is the cost of trusting the tech?
What are our options?
1- Rewrite the Service Model and migrate to another DBMS
2- Have a good Server Infra Team, and hunt down bugs as soon as possible and report them for fixation!
well yes and no :) .... sql will increase the time-complexity of document based relation systems. "custom forms" for example which now have to be stored in "deep table"-structures and my favorite edgecases -> filter systems with "having sum/count" in deep tables to find if a user has a username and a password but no email address ;D.
The next thing is location/data based sharding has to be implemented yourself -> in SQL you need one block device (usually 1 HD / partition) and every transaction is considered done if the HD gives you the write ACK.
If you consider all those details for the decision I agree you can stick with SQL because SQL has the CA of CAP but it misses the P so for network partitioning you have to think of a queue/buffer to compensate for that.
Anyhow :) I always try to pick things based on the datastructure :) so if I have a document storage and I basically never change those documents, I probably don't really care about consistency and everything that has to be consistent is in the SQL-Database anyway :)
But I encourage critical thinking :D just don't go dogmatic on it :) you probably always trade time- with space-complexity or CAP and you only get 2 out of three :)