The aversion to SQL by younger devs is pretty amazing. Yes it has a weird cognitive model and a learning curve but it's a cornerstone of web dev. Instead they resort to convoluted and technically inferior solutions like Prisma just because of a superficial DX advantage.
I'm certain Mongo only became popular because of this even though for many years it was crap.
That said I do think we need a better SQL. It's still not there but EdgeDB looks very promising.
Mongodb is very convenient for CRUD operations, while relational databases need a complex ORM to handle that sanely. Consider how much CRUD a typical application contains, I certainly get the appeal. However aggregatipn framework is horrible and thr 16MB limitation very annoying.
Im general I find SQL/relational models easy to understand conceptually, but maps badly to both the rest of the application and the problem domain.
I also hope that edgedb will help with that. When I modeled one of my applications in its SDL it was a very clean match. I don't have much experience with its query languange. But so far it looks much nicer than SQL, but still uglier than functional programming.
Those who fail to learn the lessons of SQL are doomed to re-implement it… poorly.
SQL-92 is no longer the baseline. Now we have CTEs, laterals, graph queries, JSON storage, system versioning, and more within a reasonably concise DSL for set theory.
1. The ORMs are really not updated to utilize these useful features, largely because they try to support all the databases, and end up supporting really just the ANSI standard set of features, with maybe a few extensions.
2. Without the ORM, you're writing SQL-as-string, and its as demented and awful as one would expect of writing all your code inside a random string. It doesn't help that all SQL features are made inconsistent language-wise, so you're basically guaranteed to have at least one syntax error using anything novel (with an utterly useless error message from your favorite SQL compiler), which can only be caught at runtime (because your IDE's DB linting and language support is also limited to mostly ANSI SQL, because they also try to support all the databases).
3. If you make it a stored proc/function/view, the DB IDE tooling is shit across the board. They're all miles behind any decent app-lang IDE in terms of features/tooling they provide. It's actually impressive how pathetic an environment DBA's put up with. You're really not going to get much more support than an autocomplete on table/column names, and maybe datatypes.
So ultimately, the act of writing SQL is terrible compared to doing your normal app-logic. The only reason I'm willing to put up with it is because the positives of using an RDBMS properly dramatically outweighs the negatives. But that tradeoff isn't immediately visible to the novice, so this absurdity of reimplementing SQL with not-SQL becomes reasonable.
The engine is beautiful. The relational algebra -- glorious. The language, tooling and ecosystem? It's all stuck in the 80s.
This isn't just a younger dev thing. This attitude was common even twenty years ago.
And for the record, I love both SQL and tools like Prisma. (I actually prefer Postgraphile, but that's a minor distinction without a substantive difference.)
I'm certain Mongo only became popular because of this even though for many years it was crap.
That said I do think we need a better SQL. It's still not there but EdgeDB looks very promising.