In my experience - there are a lot of organizations where old-school DBAs resist any modern software engineering practices, such as proper version control.

I think some of it is stubborness, but a lot of it is that DBAs in those organizations tend to be more "developers who happen to write DB code" and not really the A in DBA. Letting "their" code go into version control is the first step in breaking the illusion that they are somehow special, and it scares them.

Or it could be that DBAs who let the database go down get fired. I know a lot of DBAs that are old school that live in fear of any change because they get left holding the bag. They aren't special, they get blamed. It also doesn't help that a lot of new developers don't understand why "move fast, break things" is just not something any DBA of any worth is going to accept.

Based on the experience of co-workers (and my own limited dabbling), you are right that version control is (and should be) used for stored procedures just as it is with application code. The problem is that there isn't a lot of tooling that isn't language- or platform-specific to help maintain these things in the long run. So DBAs tend to write and maintain their own collection of homegrown scripts for deploying changes to the DB (or worse, do it by hand).

I'm sure some companies have this figured out, though, so YMMV.

I just make files of pure SQL to define the functions, keeping them in Git. I feed them into the psql command-line tool.

I certainly figured it out at several jobs:

- Scripts are numbered for quick order determination by humans (e.g., 0001-initial-schema.sql, 0002-create-foo-table.sql)

- A scripts.json file containing an array of string filenames declares the exact order of scripts, just in case numbers are shared for some reason (say, two branches being merged at the same time with a new script in them)

- A custom PowerShell module knows how to read scripts.json and the files and execute the changes

- When possible, all scripts are executed transactionally by the CI tool (some commands in some RDBMSes can't be executed in transactions, however)

- Optionally, backups/restores may be performed to handle failures

isn't this what sqitch does, manages deploying the changes to the db? Anyone have experience with sqitch?

I suspect it’s the shared infrastructure problem. People who are used to running a microcosm of their app locally don’t usually make statements like that in my experience.

I have a dev box with 16 GB of RAM that sits unused all day because I work with people who think this way. Such a waste of resources.