Years ago, I worked on two projects in two diff companies, and both mandated stored procs be used as a default data access method. In one case, sprocs were the only thing allowed - your credentials had no access to anything except whatever stored procs the DBA had granted you.

In both situations, the stored procedures were written by the DBA, and the DBA only. And they simply added them to the databases you needed, and then granted access. In one case, you did have 'permission' to write ad-hoc SQL, but it all had to be reviewed by the DBA.

And that was the big crux of the problem - the DBA. In both cases, they simply wrote sprocs and applied them to the databases. That was it. No version control, no testing, no application review, no sitting in on regular project meetings to understand the full problem. You'd have to describe to them what needed to be done, and they'd draft up something, put it on the server, and give you access.

So yes, these were not problems inherent to stored procedures. They were definitely a cultural problem. But those have been my exposures to "sprocs first" thinking (or "sprocs only" thinking). On most of my other projects, I use an ORM with schema definitions that are versioned, that are used to generate tables/indexes/migrations/etc, and then some queries are done by hand (usually complex reporting queries), and in some cases, stored procedures are used - maybe 90-95% queries run are ORM-generated, 3-5% are by-hand, and occasionally sprocs on an as-needed basis (slight perf boost, or logic reusable by multiple external applications are the two most common reasons).

And when I write the sprocs, they get version controlled and added to a migration process so they can be recreated in the build process as needed. By far the biggest issue I see with sprocs not being in version control is that it's DBAs writing/forcing the sprocs, and they're "too busy" for version control (or don't have the same tools, or don't understand it, or whatever other excuse is given on any day).

I suppose the problem is that many (most?) people use stored procedures without source control?

Stored procedures are often created and modified manually, directly in place, maybe by some external team/consultant, with total opacity about what SPs exist on which databases and with what code, when they changed etc.

There is of course no need for things to be this way.

Also, software development lifecycle tools surrounding stored procedures aren't as mature: unit testing tools, automated builds, linters, etc.

This puts them on more-or-less the same level as shell scripts to me. They're fine if they're tiny, in source control, and unsurprising.

You haven't lived until you had to change a 1200-line stored procedure that has at least one 8-way JOIN in it. I've worked in two different companies that had something like that.