I personally left in the era of ORMs exactly because it let me build systems in high-productivity languages and frameworks, but also because the cost benefit of RDBMS integration just wasn't there. The DB is absolutely the highest-risk place to put logic in any stack, if something goes wrong _everything_ breaks and it's the most difficult place to fix things.
I don't know what the future looks like for DBs, but I think we'll continue to see them become even more transparent. Devs just want to persist entities, and integrating at the RDBMS level is a slog.
To this end, “devs just want to persist entities” makes me both sad and frustrated. Everyone seems to default to “just use Postgres,” but then don’t want to actually use an RDBMS. If you want a KV store, then use one. If you want a document store, then use one. Don’t subject a relational database to storing giant JSON blobs with UUIDv4 keys, and then complain that it’s slow because you’ve filled the memory with bloated indices, and saturated the disk bandwidth with massive write amplification.
Counterpoint: the fewer round trips to the DB you have to do, the faster your app is.
My belief is that as DBAs more or less went away thanks to cloud providers and the rise of Full Stack Engineering, the quiet part that no one wanted to admit was that RDBMS are hideously complicated, and you really need SMEs to use them correctly. Thus, the use of stored procedures, triggers, advanced functions etc. went away in favor of just treating the DB as a dumb store, and doing everything in app logic.
As more and more companies are discovering that actually, you do need DB SMEs (I’m a DBRE; demand for this role has skyrocketed), my hope is we can push some of the logic back out to the DB. I am all for VCS, automated migrations, canary instances, and other careful patterns. I’d just like to see less of treating RDBMS as a document store, and embracing the advantages of the tech already in place.