Presumably each "version" was created by you. Version A is your starting point, no new sql scripts executed yet. You might start with a DB backup restore of version A. Create sql scripts to advance to version "B". There's your patch.

If your versions are a straight chronological sequence it's straight forward to advance from any past version to any future version. Run each patch till you arrive at the desired version.

If you branch out in multiple forks it can be a little tricky. I've never had this situation, but I would treat each branch as a separate chronological sequence of patches. Unfortunately merging doesn't work with "patch" style development, so this could be a duplication nightmare. I guess nothing is perfect.

If the customer can make unrestricted modifications to their DB (unknown to you), you're out of luck. Versions are no longer under your control and generating with a diff is the way to go. But in that case the diff seems even more dangerous. Will it destroy their custom modifications?