We need to stop using Stored Procedures

Stored procedures are unnecessary and harmful when invoked from application code. The core technical claim is that the two touted benefits of sprocs - plan caching and parameterization - are achievable equally well with parameterized queries (for example, via sp_executesql), so sprocs add no runtime advantage. Instead they introduce operational headaches: SQL logic versioned separately from application code, migrations that can get out of sync, difficult rollbacks, and DBAs who can change behavior outside app deploys. The recommendation is to colocate and version-control database access with application logic so queries evolve with the app and can be rolled back or audited alongside code.

Practical guidance for application developers accompanies that advice: learn SQL and collaborate with DBAs on indexes, query plans, transactions, isolation, sargability and parameter sniffing. Minimize network round trips, use appropriate indexes and covering indexes, and be cautious with ORMs - project only needed columns, enable query logging, and avoid N+1 patterns. Watch for cartesian explosions when joining multiple unbounded relations and break out heavy or unbounded sub-queries. Avoid generating many dynamic query bodies that bloat the plan cache; use table-valued parameters (TVPs) or other techniques for variable IN-lists to preserve plan reuse. These practices yield better performance and simpler operations than relying on stored procedures.