Database functions (RPCs) deployed straight from local SQL files are convenient right up until they aren't: rename a function in code, forget to drop the old one in the database, and now two versions exist — one live and referenced by nothing, one that git thinks is the source of truth. Multiply that across a team shipping daily, and "what's actually running in the database" quietly stops matching "what's in the repo."
Making drift visible instead of assumed
Rather than trust that deploys stayed clean, we added a CI/CD step that:
- Diffs the RPCs currently deployed against the SQL files checked into the repo.
- Flags anything deployed that has no matching source file.
- Auto-drops those orphaned functions as part of the pipeline.
Why this mattered
The value wasn't catching one bad deploy — it was removing a whole category of "why is this old behavior still happening?" bugs, where a stale function silently kept running after its replacement shipped. Schema state became a byproduct of what's in the repo again, not something that could drift out from under it across dev and main.