Athens has been incredible for me over the past week, as someone that has bounced around using Workflowy, Dynalist, and Obsidian.

The great outliner features of the first two, and the backlinking and graphing of Obsidian. My only real reservation is that files are not in Markdown. Is there a plan to address that, or is a DB central to the architecture? Currently using LogSeq because of this but eager to switch.

Yes! Good import/export functionality is important. Ultimately, it would be awesome if there was direct serialization between our database and markdown. This would allow seamless "import", the same way Obsidian/Foam/Zettlr are directly interchangeable.

What do you see as the advantages vs. Zettlr? I haven't got to a point where perf seems to be an issue that would require a real graph database and having your knowledgebase just be a collection of markdown files is the ultimate in local first no lock-in portability.

The current major difference between markdown-based and db-based apps is block references. Over time, the difference will become significant as knowledge bases grow in size.

CSV -> Excel -> SQL -> Distributed Cloud DBs

Furthermore, our database supports data types, including numbers, dates, etc. I don't think any networked notetaking app has executed well on tables and non-string types. UX for tables is generally not great for markdown.

> The current major difference between markdown-based and db-based apps is block references. Over time, the difference will become significant as knowledge bases grow in size.

That should be true, but so far it is Roam with the biggest problems with performance, from 30+ seconds of loading each time you load/refresh tab to constant lags in normal usage for some users :)

I personally like the most this mixed approach of Logseq - app internally uses DataScript, but data is ultimately stored in plain files.

It's not either or as you mentioned! Plan to have user data stored in plain files as well.

Roam's performance suffers mainly on first-load because they are server-first, and they load the entire db into memory at the beginning (such that it's quite fast thereafter).

Once we have true local-first data structures with something like https://github.com/replikativ/datahike, we could still have fast in-memory, but also fast initial load.