Obsidian vs Logseq vs SiYuan: how to choose

Be precise about what this comparison is not. It is not local versus cloud: all three store your notes on your own machine, open without an account, and keep working with the network unplugged. Within that camp they converge on a common feature set. Each has bidirectional links, a graph view, full-text search, tags, templates and an extension mechanism. Each runs on Windows, macOS, Linux, Android and iOS. Each has a free core, with the paid parts being optional services rather than the software itself.

So the choice is not settled by the feature grid, which is why reading feature grids does not settle it. It is settled by the internal model: what the smallest addressable thing is, and what is left on disk when the app is gone.

An Obsidian vault is a directory you choose. Inside it, one note is one .md file, plain UTF-8, with optional YAML frontmatter and [[wikilinks]] in the body. The application indexes that folder; it does not own it. Edit a note in another editor while Obsidian is open and it will notice.

That is the fact that matters most, and it is worth separating from the thing people usually say. Obsidian is closed source: the application is proprietary, there is no public repository, and you cannot fork it if the company changes direction. Obsidian is not a proprietary format: your notes are files in a format that predates the app by a decade and is read by hundreds of other programs. Those are two different risks and only the first applies. The worst case with a closed-source app whose data is open is that you lose a piece of software; the worst case with a proprietary format is that you lose the archive. Calling Obsidian "proprietary but local" blurs the two, and the distinction is why people who care about longevity still pick it.

The second reason is the ecosystem, which nothing else comes close to matching. There are well over two thousand community plugins, and the important ones have become de facto standards: Dataview, which runs SQL-like queries over your frontmatter and renders the results as a table inside a note, plus Templater, Excalidraw and Obsidian Git. Canvas, the built-in infinite canvas, writes its own open format, so a canvas is also a file in the folder. The project has been adding first-party database-style views of note properties too, which narrows the gap with the tools below; that area is moving, so check what has shipped rather than what last year's tutorial shows.

Obsidian does support block references, by appending a generated anchor to the end of a line, but it is opt-in and slightly grubby, which tells you where the centre of gravity is. In Obsidian the page is the unit, and the whole ecosystem assumes it.

The cost of that ecosystem is that a fresh install is not a finished tool, and assembling one is a hobby that can quietly replace the work. If you are the kind of person who will spend three evenings on themes, read digital minimalism before the plugin directory.

Logseq inverts the page. Everything you type is a bullet, bullets nest inside bullets, and a page is a container for an outline rather than a document. If you have used Roam Research or Workflowy the shape is familiar immediately. If you write in paragraphs, it will feel wrong for a week and then either click or not.

Two design decisions follow from the outline. The first is block-level addressing: every bullet has an identity, so you can reference or embed one bullet elsewhere and edit it from either place. The second is the daily journal as the default entry point. Logseq opens on today, empty, and the expectation is that you dump everything into the day and let structure emerge from links and tags rather than from folders. Capture first, organise later, which is close to how Zettelkasten and evergreen notes describe the process anyway.

Logseq is fully open source under the AGPL v3, which for some people ends the discussion. Its storage is Markdown or Org-mode files, one per page, in a folder. That is real portability, with one caveat: the Markdown is outline-shaped, so a deeply nested page opens elsewhere as nested bullets rather than as prose. The files are yours and they are text, but they carry the app's model in their shape.

The important thing to know about Logseq in 2026 is that the project has spent a long time rebuilding on a database backend rather than parsing Markdown on every load, to fix the fragility of round-tripping the file format and the slowness that shows up on a graph of a few thousand pages. That work has been visible and testable for some time and the direction is right, but it is a rebuild in progress, not a finished migration, and it changes the file story: a database version keeps notes in a database with import and export around it, not in files you edit in place. Do not adopt Logseq on the strength of a version described in a roadmap. Look at what ships today and treat the rest as upside.

SiYuan goes further in the direction Logseq points. Every element (paragraph, heading, list item, code block) has a permanent identifier, and a document is a tree of those blocks. Because identity belongs to the block rather than to a position in a file, references survive being edited, reordered or moved to another document, the failure mode that eventually annoys everyone who links heavily in a file-based tool.

On top of that model it offers what a document-shaped tool struggles with. Editing is WYSIWYG: you type Markdown syntax and it renders as you go, with no source and preview modes to switch between. Built-in database views mean a table inside a note can have typed columns, filters and sorts over blocks, the way people use Notion databases. Spaced repetition is built in rather than bolted on, so a card is a block you flag rather than a note you export to Anki. There is a web clipper and a graph view too.

It is open source under the AGPL v3 and it self-hosts properly: you can run the kernel in Docker on your own server and use it from a browser, which is why it shows up in self-hosting communities. Sync goes through the project's cloud service or an S3 or WebDAV endpoint you control, with optional end-to-end encryption.

The trade-off is the store. A SiYuan workspace is a tree of JSON files, one per document, holding the block tree, plus an index. It is not a black box (it is JSON on your disk, and Markdown import and export both exist) but it is not Markdown either, and grep over it does not do what grep over a Markdown vault does. You are storing structure, and the schema belongs to one program.

Two caveats: the English-language community is much smaller than Obsidian's and some documentation is translated, so you will do more of your own figuring out; and the project moves fast enough that a six-month-old comparison may be wrong on specifics.

The three differ consistently, and most of what follows comes from the first row.

One warning about the last two rows: pricing and packaging here change, sometimes substantially. Treat the shape of the model (free core, optional paid sync, optional paid publishing) as the durable part, and check the current terms on each project's own site before planning around a number.

• Pick Obsidian if you write in paragraphs, want the largest pool of plugins and tutorials, or care most about the folder outliving the app. It is also the safe default when you do not know yet: nothing you write in it is trapped, so switching later costs a configuration, not an archive.
• Pick Logseq if you think in bullets and capture continuously through the day, or if a fully open-source licence is a requirement rather than a preference. Go in knowing the project is mid-rebuild, and judge it on what ships now.
• Pick SiYuan if you want Notion's structure (databases, references that never break, spaced repetition) without Notion's hosting, and especially if you were going to self-host anyway. You are trading a smaller community and a non-Markdown store for capability the other two need plugins to approximate.
• Pick none of the three if your requirement is elsewhere. A shared team workspace with permissions and comments is not what any of them is for. For something simpler, or an open-source object-graph model, see Zettlr, Joplin, Anytype and AppFlowy. If you already live in an editor and want notes in the same Git repository, start with PKM for developers.

All three are good. People who abandon them rarely do so over features; they abandon them because they collected notes for four months and never wrote anything, or because the folder structure became a second job. That failure is method-shaped, and no plugin fixes it.

Two things are worth having in place first. One is a rule for what goes where, which is what PARA and CODE supply: a few buckets, organised by how actionable something is, so filing is a two-second decision rather than a taxonomy problem. The other is a rule for what a note is for, which is the contribution of Zettelkasten and evergreen notes. Both work in all three tools, which is the argument for spending an hour on the choice and then getting on with it.