> oft-changing-but-rarely-majorly data

I think you're referring to SCDs, and there are plenty of well-defined ways to track these within relational databases:

https://en.wikipedia.org/wiki/Slowly_changing_dimension

Why git?

In your git & sqlite setup, I'm not sure which way round you are thinking - which is the SSOT (Single Source Of Truth) and which is the handy cache.

I've been working on a tool that treats the git repo as the SSOT then lets you dump out all kinds of formats for data work including a sqlite DB. I haven't had as much time as I would like on it but it's at https://pypi.org/project/DataTig/

Would fossil fit this bill?

Somewhat git-compatible, based on sqlite3.

Specifically the fossil repo is a sqlite database.

I have a cron script stashing whatever is currently in an obsidian vault into a fossil repo. There's a fossil addremove command that makes that very easy. Thus distributed backups of said vault.

What does "somewhat git-compatible" mean? Can it sometimes use existing git repos, or is the mental model close enough to pick up without learning much?

> is the mental model close enough to pick up without learning much?

I would say git core concepts are pretty similar to fossil concepts, but actual plumbing implementation details are pretty distinct.

The major difference that I remember from a day-to-day "git porcelain" perspective is that rebases and other types of history rewriting are very discouraged.

For a Rosetta stone of somewhat comparable commands: https://fossil-scm.org/home/doc/trunk/www/gitusers.md

> Can it sometimes use existing git repos

You can, but it's kinda a lot of really slow busywork. And you lose some of the not-file-dvcs features of Fossil, but it is possible.

This page explains how: https://www.fossil-scm.org/home/doc/trunk/www/mirrortogithub...

Maybe this https://github.com/dolthub/dolt

Dolt is really close and yet just doesn't feel right; I don't want to "commit" between transactions, I want every transaction to be a commit.

You can do this with a setting:

https://docs.dolthub.com/sql-reference/version-control/dolt-...

That's awesome. I will have to try that out.

If anyone is coming in late, I have discovered https://immudb.io/ , which claims to be a lot of what I'm looking for. Transactional SQL database, indexed, yet immutable data and verifiable chains of transactions.