It sounds like you might be developing an app with an evolving schema.

You should consider adopting a db migrations framework and having a task that can apply them to a dev database to bootstrap/upgrade the DB. If you take this route, you won’t need to even commit the db file, and you will be able to easily seed/replicate the DB schema when you deploy it.

Additionally, SQLite is awesome, and if you are actually storing some data, you can do some stuff where you can make tables that are backed by structured text files (like CSV), so there are ways to store data in text while still getting the benefits of having a SQL interface

Large binary files will start to expand the git repo, but if they’re relatively small, and the update frequency is somewhat limited, it won’t really be an issue. If you are concerned about it, you can look into git-lfs, but it might not matter much.

EDIT: Also, since the “git is bad with binary files” is such a pervasive myth, I decided to check into it a little bit. A couple things:

Git uses “delta compression” when packing/storing/transmitting files. This allows common chunks to be stored once and then reassembled when you check out a file. It does this for “normal” files reguardless of whether they are text or binary until they are considered “big”, at which point, they are stored as a single unit in the pack file. What’s “big”? By default, 512MB.

You can go pretty deep on the internals of the way that packfiles are constructed in git, but more than likely, a file that’s a few MB is still going to work fine, and you will get some storage reduction when you commit it.

You should configure automatic gc to periodically repack stuff so that the actual .git repo doesn’t balloon, but again, even if you’re talking about a few GB, it’s still not much on modern systems.