ArchitectureBest Practices
Why Business Logic in Stored Procedures Is an Anti-Pattern
Brian Foley
How We Got Here
In the early 2000s, putting business logic in stored procedures made sense. Application servers were expensive, network round-trips were slow, and databases were the most reliable piece of infrastructure. So developers put everything — validation, calculations, workflow orchestration — into PL/SQL and T-SQL.
Why It's a Problem Now
Two decades later, this pattern creates serious issues:
- Testability — Stored procedures are notoriously difficult to unit test. Most organizations have zero test coverage on their most critical business logic.
- Scalability — You can scale application servers horizontally for pennies. Scaling a database vertically costs a fortune.
- Vendor lock-in — PL/SQL ties you to Oracle. T-SQL ties you to SQL Server. Your business logic becomes inseparable from your database vendor.
- Developer experience — Modern developers work in TypeScript, Python, Go. Finding engineers who want to maintain 10,000-line stored procedures is increasingly difficult and expensive.
The Path Forward
Extract business logic into serverless functions or API endpoints. Keep the database focused on what it does best — storing and retrieving data with referential integrity. The result is a system that's testable, scalable, portable, and maintainable.