monotone did this years ago, before git was even a thing. The main problem with it was that the sqlite file would grow very fast and reach enormous sizes as you put flies in and merged in branches. That could make it very slow. It was a full distributed change control system though, and it worked well on a few projects at the time. So the concept and even the implementation is not new.
Edit: here you go, a link http://www.monotone.ca/monotone.html I don't think that manual page has been changed in nearly a decade. We used BitKeeper in the early 00s, just like Linux, until BitKeeper got arsy about licences. We (postnuke/Xaraya) moved to monotone while Linus created git, and we later moved to git. Although having the entire system and data in one file can be handy, having it in one .git directory is also easy enough to manage.
monotone was good at that. We had a project going where all modules (plugins) were in their own folder, under a master folder on the main repository. As a developer, you could check out as many or as few of those modules as you liked, and your repo grew as you checked out more. I haven't used monotone for years and it ran like a dog on Windows, but it had some good ideas in it. It was around before git, and I suspect some of its ideas fed into the development of git.
Each repo is a single SQL database, in a single file, so it could grow quite large on big projects. It was the monolithic repo database that was the source of the speed issues IMO - once the file was cached in memory then operations ran very fast, but loading up a 2Gbyte database into memory to start with was the slow bit. git spreads its data over many files and uses compression very well.