I don't care how you slice it, versioning a DB in git is a broken process. If you have to do this to shore up a project, it indicates the project is broken.
This is sold as something for big sites: "70% of WP sites in Alexa Top 1 Million" but I promise you there is no conceivable way the amount of changes we make in our WP DB could not be handled in Git.
There are certainly big technical challenges to solve, that's why we're running the crowd-funding campaign and that's why we repeat the phrase "realistic funding" quite often. However, although I'm not saying that VersionPress will work in every thinkable scenario and for every WP site out there, we will be able to cover a lot of sites and a lot of needs WP admins have today.
I'd be interested to hear how you plan to solve that problem exactly. There are several[1] existing[2] solutions[3] attempting to solve the problem of versioning binary files in git, but even then, the history of your code and the history of your data are kind of two separate timelines. I should be able to revert, say, a plugin installation or a configuration change without having to revert any posts or comments that came in during that time. And vice versa.
The only time you'd want to tie your data with your code is when the schema of your data changes. Existing frameworks like Rails use code-based migrations for this purpose, so you know at any point in your git history what the database schema should look like (if not how to migrate/revert your data to match that schema).
Could you describe how you actually intend to version the database in any sort of technical language? There are existing methods of doing RDMBS versioning and I don't know of any that have tried using git.
If you want to do something that makes no sense, asking for money to do it doesn't make it more realistic.
VersionPress is a combination of hooks, own text format and custom PHP code that manages Git and makes it all work together. VersionPress extracts information from the database, stores is in a format that is suitable for diffing and merging and versions that in a Git repository. So we do not version control db files themselves but rather the information inside the database. Sorry if you find the term "database versioning" technically incorrect, we just had to call it something simple that would still be relatively close to the technical truth.
I'll prepare a blog post on how VersionPress attacks the versioning problem technically.
A conceptually simple way to version a relational database and keep the versions in Git (or any other VCS) is to reduce each version to a set of SQL scripts that build the database from scratch to its current state, and then commit those scripts to the Git (or other VCS) repository.
To make it tractable to do so with small, frequent, incremental changes to a DB, you'd need to be smart about tracking which scripts need to change rather than running a process to reduce the whole DB to scripts each commit.
This is sold as something for big sites: "70% of WP sites in Alexa Top 1 Million" but I promise you there is no conceivable way the amount of changes we make in our WP DB could not be handled in Git.