If the biz logic is about structured data storage and transformation, it belongs in the database.
If the biz logic relates to data validation (data types and data affinity), it belongs in the database (and probably should be checked elsewhere as well).
If it relates to data integrity and correctness (foreign keys, check constraints, uniqueness, cascade behavior, etc.), it belongs in the database.
If it relates to communication with external services (email, queues, file storage, HTML rendering, data compression, scheduling, lookups to 3rd-party APIs, pure computation, etc.), it very much does not belong in the database.
All of these are "business logic". All are important. Use the right tool for the job at hand. Set theory for the databases, general purpose computing for the app layer.
I could agree with HTML rendering and compression, but sending an email during user registration or as part of an event notification is 100% business logic.
If the biz logic relates to data validation (data types and data affinity), it belongs in the database (and probably should be checked elsewhere as well).
If it relates to data integrity and correctness (foreign keys, check constraints, uniqueness, cascade behavior, etc.), it belongs in the database.
If it relates to communication with external services (email, queues, file storage, HTML rendering, data compression, scheduling, lookups to 3rd-party APIs, pure computation, etc.), it very much does not belong in the database.
All of these are "business logic". All are important. Use the right tool for the job at hand. Set theory for the databases, general purpose computing for the app layer.