It depends.
Yes, it is a use case thing. Yes, it is also a developer experience thing. Yes, the nature of the data to be input matters (highly predictable, orthogonal, rational, and easy to normalize, OR unlikely to be normalized/organized in any meaningful way). Yes, the relationships (if any) of one record/object to another matter. Yes, how you need to analyze the data matters. Yes, the nature of the application being supported matters (how the data is to be used in the application).
Yes, it matters if the structure (schema) of a record/document must change rapidly, or if fields themselves must not be mandatory for each record/document
Yes, it matters if you have an extremely large amount of data to store and you want to reduce retrieval times. Normalized data (data in lots of separate, distinct tables) tends to require being put together (joins, subqueries, etc ...) in certain ways to return useful results. Those same results might be returned faster by just returning a few documents or collections (with some filtering).
Oh, yeah, and to make the new world order feel acknowledged ... yes, those who learned JavaScript or Python as their first programming languages are happy to not be burdened with SQL. For example, MongoDB stores data as BSON, which effectively seems like JSON to someone who only cares about getting the data they want--no schemas, just store/get the data and move on to the next thing.
Frankly, it matters which one you learned first. If you learned SQL first, then there is a place for everything and everything in its place. You do not mind defining/altering a schema because it makes know your data very well. In fact, some people prefer SQL because the enjoy the feeling of control. The do not mind knowing another domain specific language because of the power it gives to the user. Since SQL has been around since the 70s, it is basically the old school business way of doing things.
The costs of using a SQL RDBMS are time to plan and modify schemas (partitioning when necessary), time to plan table sizes and scalability (clustering), learning to interfacing with the database and translating records into programming language data structures (ORM, or other).
However, SQL it is very effective when it comes to analyzing data and asking complex questions. If you have more than simple storage and retrieval needs (with minor analytics), then SQL puts you way ahead of the game.
However, a normalized, SQL database as a monolith for an application is not necessarily great for all the data requirements of an application. There may be aspects of an application (web, or otherwise) that are not CENTRAL AND CORE to the going concern of the business.
If you want a tried and true ACID compliant transactional (with rollback) record system for your financial records (payment, purchase, etc ...)---like if you are a bank--then I am going with SQL no matter how good document databases get. However, some do-hicky widget in the UI might not even touch customer records / business transactions. Why have a schema just for that?
Effectively, that is the perspective of the core UI web developer set. They can justify document databases to make their development life simple, but not to make your business transactions ACID compliant. The more experience they gain, the more they will come to see that the convenience of document databases is just that--a convenience.
I am sure that even as I type this, someone is saying that XX document DB now has ACID compliant transactions, but does it have SQL? Eventually, those who want document DBs for everything will find a way to make it happen--it'll probably mean (among other things) that the collections and documents will have more constraints, and it begins to turn into a--GASP--form of a schema.
Look, with things like REST and GraphQL APIs, you never know where you might be getting data from. You cannot predict or plan the form of all data ahead of time. In cases like these (say, interfacing with the Amazon Web Services APIs), then a document database makes good sense. You do not want to normalize that much data. You just want to access, filter it, and do basic stuff to satisfy the needs of your application. Dumping this data into an SQL database could be a waste of time. Every time AWS updates a service with new data, you might have to change your code and schema to accommodate it. ACKKK! Just store it in collections and documents already!
The AWS API example above involves no transactions. There's no need for a bunch of tables if you need to retain some of the API information. Unfortunately, SOME PEOPLE try to make every scenario fit this use case and they would be WRONG!
Going further, given the amount of data one might ingest from the AWS API, sharding and clustering data stored in collections and documents is MUCH simpler, compared to partitioning and clustering SQL databases. If you work in operations, then document databases are easier to administer, ultimately.
So, while I like lots of answers here, many seem to put up a defense of their camp and/or only slightly explain scenarios where document databases might be more appropriate than schema based, orthogonal, SQL databases.
Rules of thumb:
- If it is CORE and CRITICAL to your business operations andgoing concern (CRUD, ACID, transactions), go SQL.
- If it is just for handling massive amounts of data for processing inapplications and UI, document / NoSQL databases.