Logseq 2.0 Beta Bets on SQLite Over Markdown

For years, Logseq sold itself on a simple promise: your knowledge graph lives in plain markdown files you can open in any editor, version with Git, and back up with rsync. That model is still available. But the 2.0 beta, tagged 2.0.1 and labeled the DB version, makes a different bet. The canonical store is now a SQLite database. Markdown export remains possible; editing those files as the source of truth does not.

That is not a cosmetic release. It is an architectural fork that other local-first knowledge tools will keep running into, and it forces a real trade-off between transparency and reliability.

Two products, two storage models

The project has split the apps. Logseq OG keeps the old file-based graphs. The new Logseq only works with database graphs. Mobile follows the same split. OG moves into maintenance mode: security patches and Electron or platform compatibility work, no new features. The DB line gets the active development budget.

Both apps still load graphs into an in-memory Datascript store while you work. The difference is what hits disk. In OG, markdown files stay canonical. In DB, SQLite is canonical. You can export to markdown later, and the team has talked about continuous one-way export, but the database does not re-ingest edits you make outside the app. That is the whole point of the redesign: stop treating the filesystem as a concurrent writer that can race the app and corrupt the graph.

If you have lived in the "notes are just files" world, this feels like a loss. If you have ever watched a sync tool thrash a large outline graph, it feels like overdue engineering.

What actually gets better

The DB version is not a pure storage swap. Tags and page references stop being the same underlying thing. Import from an existing markdown graph works, but you have to choose how tags map, and the FAQ is clear that the two models diverge enough that you should experiment on a throwaway graph before migrating anything you care about.

The payoff the team is chasing is sync and multiplayer. Official sync now aims for real-time collaboration (RTC) between multiple users. Self-hosted sync exists and the community has been documenting setups. Official sync with RTC is not free; it sits under Logseq Pro. During testing, sponsors at $15/month get access to the new sync and the new mobile apps.

That monetization choice is honest. Real-time multi-user editing on a small open-source team is expensive. A five-person, donation-funded project cannot match a subscription PKM vendor on headcount, and the forum history shows how long the alpha dragged while the team worked through sync and collaboration rather than surface polish.

Developer angle: adopt, wait, or fork the idea

For working developers the release lands in three buckets.

Daily drivers and power users. Treat 2.0.1 as an early beta. The release notes say so outright: back up first, expect rough edges, file issues on GitHub. Desktop builds cover macOS (arm64 and x64), Linux, and Windows-class packages; there is also an Android APK. A web build at test.logseq.com still stores data locally if you want to poke without installing. Plugins and themes from the OG world are not guaranteed; some authors already stopped updating. If your workflow depends on a thick plugin stack or on hand-editing markdown outside the app, stay on OG for now or run both side by side.

People building on Logseq. The schema is more stable than it was in deep alpha, but it is still a beta. Anything that assumed "the graph is a pile of .md files" needs a new mental model: queries and extensions talk to the database layer, not the filesystem. Import paths exist; reverse write paths into the DB from external editors do not. If you maintain a Zotero bridge or similar, check for DB-aware updates rather than assuming the old file watchers still apply.

Builders of other local-first tools. The interesting lesson is not "use SQLite." It is the explicit ranking of properties. Logseq chose:

• fewer silent data-loss modes under concurrent edit and sync
• a path to RTC
• export-as-markdown as a secondary, not primary, interface

over:

• "open the vault in VS Code and it is still the real data"
• free-form Git diffs as the main history model
• zero friction for third-party tools that only speak files

That ranking matches tools that want multiplayer and durable offline-first state. It fights tools that want to remain a thin UI over a directory of text. If you are designing the next notes or knowledge graph product, write the ranking down before you pick a store. Halfway designs (files are canonical and we promise perfect multi-device RTC) tend to ship neither well.

Practical migration sketch if you do try the beta:

1. Full backup of your OG graph and any sync targets.
2. Install the 2.0 desktop build separately; do not overwrite OG.
3. Create a fresh DB graph and import a copy, trying different tag/reference options.
4. Exercise queries, daily notes, and any plugins you actually need before touching production data.
5. Decide whether official Pro sync, self-hosted sync, or no multi-device story is acceptable for your threat model.

Who wins the fork

OG users who wanted a forever-markdown tool get a maintained but frozen product. That is better than a forced rewrite, worse than a thriving dual track. DB users get the architecture that can support reliable sync and collaboration, at the cost of the pure file story and with a paid tier for the full multiplayer experience. Plugin authors and extension developers inherit a harder compatibility job for a while.

Is the beta production-ready for serious work? Not yet. The team is explicit that this is early beta. Is the direction right for a tool that wants to compete with closed multiplayer PKMs while staying open source at the core? Yes. File-canonical storage hit a ceiling on conflict handling and multi-user editing; SQLite plus a controlled export path is a standard, boring way out of that ceiling, and boring is what you want under a knowledge base.

Watch the beta for stability, plugin recovery, and how painful self-hosted RTC remains without Pro. If those land cleanly, Logseq's DB line becomes a serious reference architecture for local-first apps that outgrew pure markdown. If they stall, the community will keep forking the file model, and the split will look like a long maintenance tax. Either way, the storage decision is the story, not the version number.