I'd say it's more of use the fundamentals. Learning them is, hopefully[0], table stakes. But even devs who know how to wield SQL, will be tempted to wrap it into some kind of ORM (either COTS or a DIY one), or a set of structures and functions, forming a flat and generic "data access layer" - all because that's how they've been taught the code should be structured. This is the pressure they need to resist.

That said, I myself haven't found the perfect balance. If you're going to honestly embrace the database, and follow a data-first approach, chances are you'll end up with an application that does most of its business logic on the database side.

On the one hand, it makes perfect sense - if your software is really about data transformation, there's no good reason to pull data from the DB, just so you can reshape it by hand using inferior tools not fit for purpose (i.e. most code you normally write), and then put it back into DB.

On the other hand, it feels wrong. Can't exactly say why, but somehow, having my app be a PostgreSQL database serving its own REST API, feels too direct, even if it literally does 100% of what I need. Closest I can come to explaining this is, RDBMS doesn't give me enough control - maybe I want the REST API to work slightly differently, or have more specific security needs, etc. But then, do I really need those alterations? Are they worth all the complexity and overhead that comes from writing software the "ordinary way", where RDBMS is only a dumb data store?

--

[0] - Who am I kidding...

I think you are right, but databases are complicated enough where people can have different interpretations of what the fundamentals means.

For example, is being able to write the basic SQL query enough, or do you need to know what the difference between a hash join and nested loop is?

Without a pretty deep understanding, I think it can be hard to pick out faults with the ORM, and there is always the chance the ORM might avoid making a mistake you do yourself.