> It’s code that’s much harder to get visibility into, harder to track over time, harder to reason about in the context of a larger codebase, and harder to meas

> It’s code that’s much harder to get visibility into, harder to track over time, harder to reason about in the context of a larger codebase, and harder to measure and understand the performance implications of. I think this really depends on the developers and their tools. I've seen at least one system that is built on the database using hundreds of stored procedures and triggers, and that was still maintainable. The reason that it was maintainable was that there was a code and naming style that was used consistently throughout the project, that each trigger and stored procedure was documented, and that the developers had a good tool to maintain everything. Maybe in practice it's the exception, but good coding style can help just as it would help with code in a service. > And for most cases, all this downside with little/no upside. Well... obviously there is a very important upside and that is performance: you are executing code very close to the data and this can give you a big performance gain. If you execute business code on an application server, you have to first fetch the data from the database, then manipulate the data and then send the data back so that the database can store it. If you execute business code inside the database server, you don't need the round-trip (which goes typically over a network connection) and this can result in much better performance. Personally I never built a system that relies on triggers and stored procedures. I'm used to working with an ORM and implementing business logic in the service. I do rely on database features (different types of constraints) to protect data consistency as much as possible. Still, at some point I would love to build a system that has its business logic in the database just to get the experience and to really know how that works. I also wonder how performant the language integrations (which might be more expressive than the default) are that database systems sometimes offer.