Not everyone jumped on the NoSQL bandwagon. Software development is a horrible gaping maw of fad-driven, ill-thought-out crap.
In the early days of NoSql, a lot of dev were still shoehorning graphs, objects, or giant look up tables into SQL database, and yes, it turns out that there are some wonderful databases to store and query this sort of data that don't rely on a relational model.
And then... yep, a bunch of magpies decided that SQL shouldn't ever be used. It's important to point out that plenty of people who pioneered and promoted graph databases, object databases, and so forth didn't go down this rabbit hole. When the data was relational, plenty of these folks were all for relational databases.
But I don't think you can claim the "NoSQL => never use SQL => SQL is obsolete" crowed was just a few outliers. This opinion infected a lot of software development organizations, and did plenty of harm.
I love SQL, but let's not get too enthusiastic about sending the pendulum swinging back the other direction, even if tempting to watch it knock a few of the overly zealous NoSql types off their perches. Trust me, I still feel a flash of anger inside when I think of some of the arguments I had to go through when I advocated for relational SQL databases. But I don't want to be that guy myself - plenty of non-sql data bases are really well conceived and designed, and are ideal for the problems they address.
Trying to deal with object/relational impedance by sticking an object-oriented API in front of the database, and then using that to shoehorn OO ways of organizing and accessing data into an RDBMS, is a great way to place an upper bound on what kind of performance you can get out of the database. It also makes (what should be) routine schema migrations much more painful than they need to be. I think that that can explain a lot of the perceived success people were seeing with many document stores.
In short, the developers more or less used the ORM to serialize and object and write it out to disk. The persistent data basically makes no sense on its own, it has to repopulate the objects before it can be accessed in any meaningful way. There's little doubt that the devs behind these project had very little understanding of what an RDMBS actually is.
And if you don't, then I suppose NoSql makes sense, because your data is never relational - not because it the relational model wouldn't be helpful, but because the developer can't see the relational model in the data stored, and is incapable of structuring it this way.
I remember this idea (paraphrasing)[2] - the data will outlast the application, and the application will most likely outlast the developer.
To me, this led to a design principle - the database should always be useful outside the context of the application. If you want information about the data you're storing, the DB should be a very, very useful place to get it. I'm not ruling out the value of the app! There are lots of ops you'd want to do as a combination of code and data, lots of UI, plenty of things. But if your data is useless and nonsensical unless your app transforms it, that is probably a sign of a big mistake[3]
[1] I love rails, and I like ORMs. They save me so much typing compared to the old days of JDBC. It turns out it's not all that hard to create a well organized relational database through generators, and if you prefer to design the DB separately, it's not hard to map models to db tables. It really only gets out of control when people are essentially designing an RDBMS through generators and an ORM, but have no idea what idea what it all means on the backend.
[2]https://blog.jooq.org/2014/01/02/why-your-data-will-outlast-...
[3] probably
When I converted our application to Rails, I had a database that was pretty home-grown, as we were using a language/framework where you tended to write raw SQL. While I was able to tweak the model files to work with our schema, in most places I found it too challenging to construct ActiveRecord queries, and ended up writing a lot of raw SQL (or rather, copying it from previous iteration). Initially I thought I was doing it wrong because it wasn't Railsie enough, but realized that our database is our asset, and Rails is secondary. We do a lot of ad-hoc querying and report writing, so I definitely think database-first is the way to go in our use case.
Therefore, developers tried to minimize their need to go through a DBA by doing more data-ish things inside the application itself. That's more of a staff management problem than a technology problem, but OOP had the "fad cred" of the time and often bowled over DBA's. The pendulum has started to swing the other way as reinventing the database & querying in applications has proved messy.
On a side note, I was pretty excited that graphcool got open sourced, but their json limitation to 64kb is a dealbreaker.
I think there's a class of developer that is very against "old" ways of doing things and has driven a lot of that narrative.
The query language and hardware scaling are mostly two separate issues, and the NoSql movement unfortunately confused the two. It's mostly that SQL-based databases were slower to scale up, not that SQL is a horrible query language.
As far as query languages, I've been in long discusses and debates about alternatives to SQL. I was partial to a draft language called "SMEQL", but everyone has different opinions on what a query language should look like and emphasize: it's hard to make everyone happy.
Words such as these deserve a poster to live on.
https://cacm.acm.org/blogs/blog-cacm/50678-the-nosql-discuss...
http://www.labouseur.com/courses/db/Stonebraker-SQL-vs-NoSQL...
https://www.barrons.com/articles/michael-stonebraker-describ...
https://blog.jooq.org/2013/08/24/mit-prof-michael-stonebrake...