I don’t know if Git’s storage is deserving of this level of scorn—I can’t lay claim to any in-depth knowledge, but if it were indeed a big problem I’d expect it to come up frequently in comparisons with Fossil, which stores things using SQLite. (As a counterpoint, I use git-annex quite a bit, and it almost certainly couldn’t integrate as neatly into Fossil’s storage approach as it does into Git’s.) So I’d appreciate any details here.

All that is beside the point, though: the article above is not about using or not using flat files as a storage primitive, it’s about using files of whatever nature as a replication and version reconciliation mechanism, in view of the fact that concurrent editing is inevitably application-specific, so we might as well lean into it instead of leaving it to a database. In that sentence, “a database” is not just any database, it’s one of a very short list of multimaster databases with relatively loose schemas, which includes CouchDB and—among legitimately FOSS projects—I’d struggle to name more.

This is not a decision about data storage at all, in other words. It is a decision about protocols. Experience shows that the alternative does not end up being an off-the-shelf database (even CouchDB, which does seem like a major road not taken looking back at Canonical’s efforts a decade ago), the alternative is usually a central synchronization server speaking a custom protocol. (CalDAV, CardDAV, Bitwarden, etc.)

And if you want to do your CRDT or OT or whatnot over per-client SQLite databases instead of per-client text files, all the more power to you.

Finally, I tried to phrase my comment above in a way that makes it clear that it’s a suggestion of a direction to have fun in, not of a principle to architect your production app around. So the sneering in your comment is... honestly disheartening to read. Like, do people even hack anymore? I know they do, but every time I read something like this I become a little bit less sure of it.