For me this kind of tool needs to provide a way to sync between devices to be useful, and ideally be available on mobile. As it's using sqlite3 to store documents, it's probably not trivial to sync with something like Dropbox.
It's even worse - Dropbox can corrupt the database file even without conflicts - it's not safe to copy database file which is currently open in some process since it can change within the reading operation. I mean, the original file stays OK, but the copy will be likely corrupt (and in this corrupt state synced into another instance).
For safe copy, Dropbox would have to force some FS-level snapshotting, but that would halt all database operations. I have received few bug reports for my app which were eventually traced into attempts to sync it with Dropbox and similar services.
I much prefer separate text files for any minimal notes solution, since that plays well with nvAlt, Obsidian, 1Writer, etc, and is the safest sync in every file syncing service (they pretty much all know how to deal with text conflicts). It also lets me write side tooling to crawl and process notes much more easily than if I had to hit a database.
At this point, a proprietary database had better be justified by something epic like Roam's bullet transclusion or Evernote's back-end handwriting OCR, or some other killer feature that's hard to replicate locally in decoupled files. Otherwise, it's just not worth even considering.
The library is properly an example of a DBMS: database management system, it's only "a database" informally to lay users.
Even basic things like backlinks are not possible (to do well) without some sort of indexes and overall control over data.
(assuming we're talking about large amount of data, 100 notes does not constitute "knowledge base" IMHO).
To your point, I'm sure it caches a fair amount of that analysis in its .obsidian directory, but to mine, it can still calculate them from scratch on a new (or newly synced) note set. It does so invisibly the first time it sees the Vault (or the new file in the Vault directory, if you add it from elsewhere), so it's still portable, just with an indexing phase if you want to show a backlink or graph pane.
The important thing for me is that most other plaintext notes editors support the forward [[links]] that are the only real "source" data. The implied backlink analysis is just that, results of an analysis. It'd be nice for the cache to be portable, but not necessary.
Transclusion is where I'd agree with you, since that actually appears in the notes themselves rather than as part of an active sidebar. You're more or less stuck with proprietary software that knows how to look for anchors and render their targets inline, at least until/unless we get a generic format for it. But so far that's been more a reason I can't have transclusion yet than a reason why I'd move off plaintext notes in a directory.
I needed it on very different devices and on mobile.
It is a web app, but it is coming with export functionality.