Fossil uses SQL and is very Git-like in many ways (but with an opinionated, merge-hap-hap-happy UI), and definitely is graph-like in its schema. That tends to

Fossil uses SQL and is very Git-like in many ways (but with an opinionated, merge-hap-hap-happy UI), and definitely is graph-like in its schema. That tends to prove that, indeed, there's nothing that special about Git that makes it not like other databases. Commit metadata is decidedly relational (or, rather, can be modeled as such). Commits have zero, one, or two parent commits (thinking of root commits as parentless), they have an author, a date, a commit synopsis and a commit message, a root object, and maybe some other metadata (e.g., who pushed, who signed off, etc.). That's all perfectly appropriate for a relational DB. The main issue that has come up over time with Fossil-style DVCSes is the size of the metadata you must keep and examine to do things like `git log -- some-file`. The metadata size issue is always going to be an issue, but maybe an ad-hoc DB can wring more compression out than a general purpose DB. Git itself had the second problem, and it had to get solved by using a Bloom filter to reduce the set of commits that need to be examined.