It's a non-starter for me because I sync my notes, and sometimes a subset of my notes, to multiple devices and multiple programs. For instance, I might use Obsidian, Vim and tasks.md to access the same repository, with all the documents synced between my desktop and server, and a subset synced to my phone. I also have various scripts to capture data from other sources and write it out as markdown files. Trying to sync all of this to a database that is then further synced around seems overly complicated to say the least, and would basically just be using Trillium as a file store, which I've already got.

I've also be burnt by various export/import systems either losing information or storing it in a incompatible way.

Some people have different requirements. Some have been burned by a program becoming obsolete or migrating between programs and finding out getting their data was (at least initially) beyond their capabilities. Some don’t see the tradeoff of having true rich text as worth it.

I’m not in that camp, but I can see the appeal.

The summed up version of your comment is that you also go out of your way to work around the database issue.

I just simply set up a script to export my Trilium notes

edit the notes with an external editor, and then you can just re-import the note

Those two lines right there.

I value interoperability between software. Using a container format to store plaintext files and metadata introduces an XKCD 927 situation where it's just another reinvention of the wheel that requires additional software support or a whole other workflow for no real benefit. Why is it necessary, for example, to store plaintext data and the related hierarchical structure in a container format when the same feature is already present in the filesystem with files and directories? It adds unnecessary complexity, roadblocks, and points of failure.

I'm using QOwnNotes at the moment. If I want to edit a note, for example, using neovim through SSH, all I need to do is navigate to the markdown file and open it. No scripts, no export/import. Only text files, and that is all it ever needs to be.

It makes for very handy use cases where other applications can work on the same data. This could be easily adding content into your notes (without needing an API to do so), using external editors for working on certain aspects of your notes, or even just the super handy convenience of having everything in one directory structure.

My Obsidian notes are right inside the same folders as the PDFs and other resources they refer to. I don't have to have a tree structure inside my notes and then the same tree structure in my hard drive or Dropbox or wherever with all my other files.

I was a 10+ year Evernote veteran, and I couldn't go back to the single DB style like Evernote or Trillium. I wish there was an open source competitor to Obsidian, but alas not yet.

And as @acockworkorange@mander.xyz rightly points out, people (me!) have been burned in the past by a program becoming obsolete and having your files stuck in some proprietary format. Plain files right in a folder on the disk is the way to go.

Why would I want to do the extra work when there are other options available that just don't store the notes in a db?

Most of those options are the traditional text-based, "page" based type notes. There really aren't that many options in terms of competition to something like OneNote though, where the "page" isnt a fixed size, and supports more than just plain text such as handwritten text, or images, or stuff that doesnt necessarily fit in a neat little square.

Dont get me wrong, there are some fantastic note-taking apps out there that are dead simple to use, but if you're looking specifically for something like OneNote, then again, super limited options.

Nope, all immich metadata is stored in the db, maybe the files themselves are in the folders, but all info on albums and tags and such would be lost in immich database in 20 years time.

While my 20+ years of photos with metadata stored and sorted by album/folders will still be accessible in the next 20 years.

Its a matter of not depending on one tool specific formats but on standards and easy accessible metadata.

Nothing against immich at all on my side.

Ok. I'll follow it. Dazzle me. 🙂

The open source equivalent of obsidian is Logseq

Not sure how it actually compares as I have not used obsidian but I love it, it does enough for what I need

Obviously.