The whole no-sql era was caused by various performance issues that made the SQL databases of that era unusable, or difficult to work with for certain kinds of workloads and data needs. As SQL databases evolved to support these workloads with features like JSONfields, the need for highly specialized database servers is less than it was, but there are certainly places where noSQLs shine. Cache and data structure servers, schemaless for persistence where everything is defined in frontend code, huge scale, etc...
> the noSql databases, like Apache Solr
SOLR (and Elastic Search) is a search engine, and is not a database, and should never, not be confused as one.
> We do not store information in countless tables with increasingly akward joins between them,
The whole "no joins" thing was really silly as the first thing that you do when working with a noSQL is write code like this parent=someThing.get(someObject); children=someObject.get(childrenMatchingCriteria); Which is a join. What Mongo and other noSQLs did was ship a reasonably performant and more importantly, easy for the developer way to store JSON objects. I spent a good number of years building on CouchDB, Firebase, DynamoDB and Mongo because it was easy to go fast, especially where the back end was just storing settings objects... Ironically, every project eventually needed two things that noSQL was supposed to not need: schemas and joins... so we implemented them in code (often in a React, Angular or Vue frontend).
The primary issue is if you are trying to model information the way humans use it and need it, relational tables are just not even close, hierarchies are a disaster, etc. We humans don't have/use tables mentally.
The answer here is, like all things in tech, it depends. It depends on what the data is. It depends on what you want to do with the data. It depends on what expectations are being made about that data.
> We humans don't have/use tables mentally
I just ate lunch. When I stepped in they wrote my name on a list with the number in my party. The server wrote my order on a paper with one grid line per item. Two tables, the old fashioned way. Tables are very natural for people. Evidence: the enduring popularity of spreadsheets, and lunch.
Humans think in terms of categories of thing. The reason things live in the same category is that they share the same attributes.
The relational model works really well for this.
I'm ready to be convinced otherwise, but I'm going to need some really good examples of "human data" that fits NoSQL systems but can't be reasonably represented relationally.
Try doing recursive hierarchical traversal with SQL, something we humans do all the time, like realizing something is a person over there, and then instantly having access to all the inherited properties of a person, and then predicting what might happen next based on that, etc.
> the noSql databases, like Apache Solr
SOLR (and Elastic Search) is a search engine, and is not a database, and should never, not be confused as one.
> We do not store information in countless tables with increasingly akward joins between them,
The whole "no joins" thing was really silly as the first thing that you do when working with a noSQL is write code like this parent=someThing.get(someObject); children=someObject.get(childrenMatchingCriteria); Which is a join. What Mongo and other noSQLs did was ship a reasonably performant and more importantly, easy for the developer way to store JSON objects. I spent a good number of years building on CouchDB, Firebase, DynamoDB and Mongo because it was easy to go fast, especially where the back end was just storing settings objects... Ironically, every project eventually needed two things that noSQL was supposed to not need: schemas and joins... so we implemented them in code (often in a React, Angular or Vue frontend).