[rakoo]

Git and Fossil ultimately deal with fundamentally the same data in the form of atomic artifacts. git chose the way to store the blobs itself on the filesystem so it had to implement a special file format along with special tools to make sure those formats could be read and written correctly. Basically git's interface to the storage are open() and read() system calls.

On the other hand fossil chose to store its artifacts in a SQL database because it makes interaction much much easier (it's just a SELECT; the SQL engine does the rest). Moreover, since fossil has access to a SQL database, it can cache a lot of information to make future extraction of information easier: instead of scanning the whole database on every read (or building a custom index as git does) you can create custom tables for your use case that point to the correct artifacts. Oh and SQLite is just an implementation detail, the real thing that matters is SQL.

So the real advantage of using SQL(ite) is in querying the data to produce all reports you want: list of commits/checkins, list of changes related to a file, list of issues linked to a given file, ...

That said, when you have an extremely simple data model and you have few different access patterns for which SQL wouldn't be of great use anyway, you can have your own file format as git does.