Should database only store data?

Very old subject I remember to discuss in the middle of 1990s... But some people still says that a clean architecture should remove all business logic from the database.

Let's start from referential and domain integrity rules (constraints). Are they business ones? Yes, of course. The e-mail column should be unique in the table because of application logic. Any adepts of "clean approach" prefer to not mention this.

Step two. Were DBMS created in 1960s to only store data? No they weren't of corse. You can use any simple tools to store data like "flat file" but the final goal is to be able to extract from these data for user needs.

So you need a query language; otherwise welcome to the pre-SQL world where any data extraction should be implemented as a small program like Python over NoSQL does today.

A usual database query is a declarative language program; its Python counterpart will count 10 times more lines of code. However, the complex queries may have many dozens or even small hundreds of lines. Is it business logic code? Yes, of course.

Finally, the real world typical case.

• Let's take Mongo - it's fashionable, stylish and youthful
• Hurrah! We have loaded all data easily. But, damn it, there's something wrong with the queries...
• Switching to Postgres... Although it is not youthful, but still fashionable, and claimed as free
• Hooray! Queries became easier to write in this powerful human-friendly language now. But damn it, why is it so slow? Do Oracle and Microsoft want our money for their query optimizers and storages developed over decades?
• No, we don't have a money to buy a DBMS from Big-3, so we will have to move many parts of the calculations from queries and stored procedures to the code of services written on Node.js...