If you're talking about storing business logic in the database for building an MVP, e.g. using stored procedures and views in your app, then yeah, go for it. Deal with the existential risk (your business might not work) before you deal with the risk of needing to fix tech debt.

If you have the resources to avoid putting business logic in the database, in a production app context, I'd avoid it if possible. It's just another thing tying you to that database, and if you ever decide to migrate, it's another hurdle preventing you from doing that.

Are you talking about at the schema design level or more from a stored procedure point of view?

Can you give an example of the business logic you have in mind?

I was thinking in terms of what level of detail is preferred in a database. Is it merely the database schema? Is it adding constraints and data validation logic to that schema (or placing that outside in your programming language code)? Or is it also adding (stored) procedures using the database language too? I'm guessing that everyone will have a different opinion based on the projects they've worked on.