How do you know that a binary is produced by some code in git? Because you built it. Same principle applies.
But also, the db can list its code.
If you have everything under version control you can just reapply that version's stored procedures off the database scripts. If someone or something is not handling failures in deployment scripts (not just database migrations) then you get that sort of problem.
In the callback script every function is declared to be created or recreated. As Flyway is executed with each application start, the database functions are recreated with every application start, even if they didn’t change.
This approach has its pros and cons but it ensures that database functions always match the version of the application code.
Because the callback script of a database function is stored in a file that is edited when needed, the Git history works the same as for application code.
But a tool like Flyway versions your DB. You know if you are out of date as the migration table is behind.
It's not as good as compiled code but it works when you need it.
My experience differs. How do you check that the stored procedures in the DB are exactly as defined in Git?
I remember spending several hours on a bug that was caused by an altered stored procedure. One SQL function was not as it should have been. I don't know if someone had patched it live, or if there had been an unnoticed failure in a DB migration script.
With a compiled executable, consistency is guaranteed. With interpreted code (Python, PHP), consistency check is done with a command like `git status`. But there is no standard way to compare the state of store procedures in the DB with their expected code in versioned files.