Logseq database migration: what actually changed
Nothing converts automatically, nothing is forced, and your existing file-based graph doesn't change shape while you're not looking. Here's specifically what "the Logseq database migration" means, sourced from Logseq's own documentation.
This page is the specific, sourced version of the question Logseq alternatives after the database migration covers more broadly. If you just want to know whether your graph is affected and what the DB Graph Importer actually does, this is that answer.
What moved, and what didn't
| Question | Answer, from Logseq's docs |
|---|---|
| Does my existing graph convert automatically? | No. Nothing in the published documentation describes an automatic conversion. |
| Where does the database version store data? | Locally, at ~/logseq/graphs/<graph>/db.sqlite — on your machine, not a cloud service. |
| How do I move a file-based graph to the database version? | You run it yourself: the DB Graph Importer, from the Import menu, described as converting "a file graph to a DB graph" by importing your markdown files. |
| Can I still edit the database version's notes as text files? | No. The database is the source of truth; direct file editing is a file-based-graph feature only. |
| Is there a way back out to plain markdown? | Yes, but lossy: "Export as standard Markdown (no block properties)," which Logseq's own docs say "cannot capture all data in a graph." |
| Is there a lossless export? | EDN — called "the only export type that fully captures a graph's data and is editable," though the docs add it "is not yet recommended as the only means to backup a graph." |
The practical takeaway. If you have a folder of .md files next to your graph right now, you are on the file-based track and staying there is the default — you'd have to run the importer yourself to change that. The migration only affects you the moment you go looking for the database version specifically.
Why two products instead of one migration path
Maintaining a flat-file backend and a database backend inside one codebase means building, testing, and explaining every feature twice. Splitting into two tracks lets each move at its own pace instead of both being held back by the other — a reading of the engineering tradeoff, not a statement from the Logseq team. The fuller argument, including why this matters if plain-file ownership is why you picked Logseq, is on the alternatives page.
A footing no migration can split out from under you
The book builds on plain markdown files from the start — no database track to choose between, no importer to run later.
Get the bookFiles that stay files, kept current by AI
The same plain-markdown base, built for a company, with an assistant filing into it rather than a product roadmap deciding the format. Try the demo.
See the demo