I disagree that we should be happy about moving data out of the storage layer into the backend in cases where it does not make sense performance wise.
The problem is doing some processing in SQL in some cases has a huge performance advantages over moving data to the backend.
If your business logic requires you to take a million rows from table A, apply some rule, and output a million rows into table B -- then piping all that data through a backend is a bad solution performance wise. I reject the idea that all that extra IO (+extra overhead also for the database) is worth it just to use another programming language than SQL.
What we need is better alternatives that execute at the storage layer. Probably starting with proper languages that compile to SQL, like we saw with JavaScript.
I disagree that we should be happy about moving data out of the storage layer into the backend in cases where it does not make sense performance wise.
The problem is doing some processing in SQL in some cases has a huge performance advantages over moving data to the backend.
If your business logic requires you to take a million rows from table A, apply some rule, and output a million rows into table B -- then piping all that data through a backend is a bad solution performance wise. I reject the idea that all that extra IO (+extra overhead also for the database) is worth it just to use another programming language than SQL.
What we need is better alternatives that execute at the storage layer. Probably starting with proper languages that compile to SQL, like we saw with JavaScript.