[Clubber]

Data integrity is maintained through FK, unique indexes, proper modeling, etc.

Also, an RMDBS is hard to scale horizontally, so the more CPU tasks you put on it, the sooner you will hit a bottleneck that is not easy to get out of. A application layer, if designed properly can scale a lot more.

>The app will be gone long before the data.

When this ever happens, it happens rarely, and the situation is the data enters a read-only state in my experience and happens during sunsetting. Most of the time, if a new system is required, a migration occurs to a new schema that the new app supports.

[ashinybrowncoat]

We use a mix of SQL and NoSQL databases for different and specific purposes. Your suggestion is to do the data manipulation outside of the database which typically means pulling data sets out, doing something with them, and then putting them back in. That will never be more efficient than just doing it in the database. Our SQL databases are actually scaled horizontally using read replicas since writes are much less frequent than reads and we can easily add/remove instances as demand grows and shrinks. IMO, it wasn't any more difficult to scale out our databases than it would have been to implement any other K8 (application or DB).

[tstrimple]

> Your suggestion is to do the data manipulation outside of the database which typically means pulling data sets out, doing something with them, and then putting them back in.

It doesn't mean that at all. You can still leverage SQL to get amazing performance for queries and mutations across large datasets without burying that in a stored procedure. Yes it's generally a bad idea to pull thousands of records across the network and into memory to manipulate them before putting them back. But that's a false dichotomy.