What the Logseq DB import drops: a checklist before you migrate

The Logseq database importer keeps most of a well-formed file graph, but not all of it, and the gaps cluster in predictable places: text outside bullets, YAML frontmatter, tags, blocks with more than one query or embed, and graph size. Run it on a copy, count what came across, and keep the file graph until the count matches.

The importer is part of Logseq’s database version, which is still labeled beta. The current release, 2.0.2 from October 7, 2026, is titled “Beta Testing”, and the project’s README says plainly that “data loss is possible” and recommends a dedicated test graph. That isn’t a reason to avoid it. It’s a reason to check the result before you trust it.

What the importer is

In the database app, open the three-dots menu, choose Import, then File to DB graph. It converts an existing Logseq file graph, the folder with pages, journals, and logseq/config.edn, into a new SQLite-backed graph. Your original folder is left alone.

It is a converter for Logseq graphs, not a general Markdown importer. A plain folder of notes from another app needs to be placed inside a valid file graph first, and one hands-on test hit the error “Import failed as the file ‘logseq/config.edn’ was not found” until a minimal config file was added.

What converts cleanly

Logseq’s importer documentation describes the mapping:

• Task markers become the new Status property: LATER to Todo, NOW and IN-PROGRESS to Doing, WAIT and WAITING to Backlog.
• Properties get typed automatically as Number, Date, Checkbox, Url, Node, or Text. When values conflict, the importer falls back to Text.
• Assets are copied and renamed to unique ids. On desktop, Zotero PDFs come along.
• Headings, icons, journal timestamps, and PDF annotations were the focus of the 2.0.2 fidelity work, according to its release notes.

The documentation also promises that the importer will “loudly error or warn when something doesn’t fully import.” Read those warnings. They are the start of your checklist, not the whole of it.

What it drops or reshapes

Source content	What happens	Where it’s documented
A block with several queries, embeds, or quotes	Only the first one imports	Logseq docs
A block mixing queries, embeds, and quotes	Only one of them imports	Logseq docs
#tags	Converted to the new tag type by default; inline tags vanish from the text if you tick Remove inline tags	Logseq docs
Page-level tags	Moved to a Page Tags property	Logseq docs
Prose outside bullet blocks	Lost in one test on 2.0.1	Computing for Geeks
YAML lists like tags: [k8s, idea]	Split into tags named [k8s and idea] in the same test	Computing for Geeks
Namespaces like project/alpha	No longer a hierarchy; tags and their parents replace them	Logseq forum

The two test findings come from a single author’s 10,000-note benchmark run on 2.0.1 in October 2026. The first import finished with almost every page body empty, because the importer kept only lines that started with -. Re-importing a bulleted copy worked, but took 40 minutes, and the resulting graph directory was about 14 times the size of the source. The 2.0.2 notes don’t mention either fix, so treat both as open until your own count says otherwise.

Tags deserve a decision rather than a default. In the database version a tag is a structured type with properties and inheritance, not a page link. If you used tags loosely, as “anything I might search for,” converting all of them produces a lot of types you’ll never use. The import dialog lets you convert only specific tags and turn the rest into page references.

The checklist

Do this before the import, on a copy of the graph folder.

1. Back up the folder. Zip it and put the zip somewhere the app never touches.
2. Count your pages and journals. ls pages | wc -l and ls journals | wc -l give you the numbers to compare afterward.
3. Find prose outside bullets. Lines that don’t start with - are the ones most at risk. grep -L '^\s*-' pages/*.md lists pages with no bullets at all; open a few of the others and look for loose paragraphs at the top.
4. Find YAML frontmatter. grep -l '^---' pages/*.md lists files that start with it. Pages written in another app and dropped into the graph usually carry it. Convert those tags to Logseq’s tags:: property first, or plan to fix them by hand.
5. Find crowded blocks. Search for blocks holding more than one {{query}}, {{embed}}, or quote. Split each into separate blocks before importing.
6. List your tags and namespaces. Decide which tags should become real tags, which should become plain links, and how each namespace maps to a tag parent.
7. Run the import on the copy. Note every warning the importer shows.
8. Compare. Page count, journal count, and five pages you know well, opened side by side. Check one page with prose, one with a query, one with an embed, and one tagged page.
9. Keep the file graph. Don’t delete it until you’ve worked in the new graph for a week or two. Logseq OG still opens it.

If step 8 turns up losses you can’t fix, you have three choices: stay on Logseq OG, which still runs on your files, fix the source and import again, or take the moment to ask whether the database version is the destination at all. Our Logseq OG vs database guide covers that decision.

A reversible trial somewhere else

If you’re migrating anyway, it’s worth trying one project outside Logseq before you commit the whole graph to a beta. listlis is a keyboard-first outliner where everything is one tree, each node a title with an optional Markdown body. It imports Markdown files directly, which makes it an easy place for a one-project trial.

Copy one project’s pages from the file graph. Open the command list with ? and choose import and export, then select the .md files together. Each file becomes a top-level node; bullets become nested children, and lines that aren’t bullets go into that page’s Markdown body instead of disappearing. The whole import lands under one new section, so one delete undoes it. Confirm your email first, since an unconfirmed account holds 100 nodes.

Then work it from the keyboard. Press / and search for TODO, press ! on each live one to make it a real todo, and c to complete it later. Fix any nesting with Tab and Shift-Tab, and add the next step with o.

Know the limits before you start. listlis has no block references and no query language, so ((refs)) and {{query}} blocks arrive as text. If your Logseq work runs on those, rebuilding queries as saved views shows how far smart lists go, and where they stop. listlis also keeps your tree on its server rather than in a local folder, and it exports the whole tree as Markdown or OPML from the same panel. The import page has the full table of what transfers.

The short version

The importer is good enough to try and too young to trust blind. Back up, count, fix the shapes it handles badly, import a copy, and compare. Keep the file graph until the new one has earned it.

If you’d like to see one project in a different shape while you decide, open listlis and import it. No setup.