Hopefully they at least got something out of it for themselves from that VC money.

(and for real-time collab, which I can totally believe is much easier with a DB. but I can't imagine most people will use that, though some (especially paying ones) will)

Clearly there's some other bottleneck beyond "it's stored in .md files". The whole DB move smells to me like "pay us for sync", not "this is better for everyone". Which is in some ways completely fair, it's a lot of work for a free tool and they deserve some income, but it feels very disingenuous when it's done like this.

---

1: I originally thought the perf issues people were seeing were on "large" collections (e.g. thousands) where some latency is quite reasonable, but no - on a modern machine with only like 10 files and a few kilobytes of text total, it can take nearly a second to update linked references, and in some cases it locks the UI while it does so. With my ~200 file, relatively-simple use it still hovers around a second (slower than when I started, but not substantially), which is definitely in the "usable" realm - I use it and like it, it fits my brain better than obsidian, I just have many questions.

It also means the file based syncing I use is not going to work anymore, which... On the other hand... Is maybe right out for me.

It’s sad because Logseq felt like a more focused tool than either Emacs or Obsidian, and really nailed the UI/UX that I wanted. But the interface was slow and buggy, and both the Org and Markdown backends are sufficiently non-standard that I didn’t want to continue writing my notes in that unless I believe Logseq is going to be around for a while. And I’m not at all excited by the large investment in the database backend, given that being backed by plain text is their largest feature from my point of view.

While I like using .md files, I can understand the perspective of needing database level syncing.

I haven't kept up with it, not sure why the existing Logseq didn't quietly start using a database internally, and also output .md files too to have both worlds.

Syncing text files can, does and most often will break given enough complexity and multi-device usage, especially with the most basic use case of using a daily note on multiple locations at the same time.

I do version control by exporting the .edn (a serialized file that contains all nodes) and using git.

All of that is very alpha (to be honest, I don't understand them releasing a beta now). You need to hang in the discord from time to time to make sure you do not miss a thing. I think my note app being open-source is pretty important to me that I still deal with that.

Though because of this tagging thing, it seems very "AI-ready" in the sense that queries are naturals as some block have an identity.

An example: I have a tag called job-application which has a status (like a checked box) for applied, in-process, awaiting-input, discarded, ... and I have a tag for the pages that corresponds with my research projects, with status (published, chased, forgotten, ...) and some information (GitHub, collaborators, ...).

there are views that summarize this (all projects, all jobs application)

When I mention a person in my journal, it's very easy to see how my last meeting with them went and all.

I don't use sync, I've been told it works really well.

EDIT: I forgot to say you can enable a markdown-mirror and have one way sync (DB->MD) which is very convenient for agent, or if you like markdown.