I agree. How often do you need to change your RDBMS? Hopefully never. And how often do you see people wanting to rewrite everything in a new language or framework? A little more often. I think many developers are just not as comfortable working with databases.
> I think many developers are just not as comfortable working with databases.
It's because databases are seen as a liability. They are often seen as complicated to test,"un-agile", hard to manage... in fact DBA used to be a job itself. Now developers are asked to be developers and DBA, which leads to over engineered application layers and under engineered data layers, or the rise of things like MongoDB.
In a world where people are trying to push Javascript everywhere, from top to bottom, SQL,schema,migrations, stored procedures, triggers are seen as a relic of the past when in fact, they are a guarantee of stability, robustness and integrity. Maybe it is SQL that should be pushed to upper layers instead ( LINQ,HQL,DQL,... ).
I was taught to use the database where it's appropriate - a well written stored procedure and something light like Dapper [1] will save you time over trying to do everything in the DB or everything in code.
Losing the DBAs from an organisation might look good on the balance sheet, but it's going to cost you big time in the long run *
"In a world where people are trying to push Javascript everywhere, from top to bottom, SQL,schema,migrations, stored procedures, triggers are seen as a relic of the past when in fact, they are a guarantee of stability, robustness and integrity."
With PLV8 for Postgres you can write your stored procedures in JS, making your entire stack essentially the same language. I've run a couple of production apps like this and it's worked better than I expected. No DML is allowed, just executing of the stored procedures, which lets us refactor the underlying tables pretty easily.
