Logseq OG vs the database version: which should you use?

Short version: if plain Markdown files on your own disk are the reason you use Logseq, stay on OG and make peace with the fact that it’s frozen. If you’re there for fast queries, linked references at scale, and sync across devices, the database version is where the work is happening now, and it’s worth setting up on a copy of your graph. If you read those two sentences and felt nothing, that’s a signal too, and there’s a third door at the end of this post.

The split became official on July 13, 2026. Logseq announced that the app is now two products: Logseq OG, the original file-based Markdown version, and the database version, released as a public beta. OG moves to maintenance mode. That’s not a rumor from a Discord thread anymore, it’s the roadmap.

What “maintenance mode” actually means

It means security fixes, patches, and Electron and dependency upgrades. It does not mean new features. The app you have today is roughly the app you’ll have in two years, minus whatever breaks when the OS underneath it changes.

It also does not mean a shutdown. There’s no forced migration and no deadline. Your Markdown files keep working, your graph keeps opening, and nobody is going to take it away from you. If you’ve been bracing for a “your data is at risk” post, this isn’t one.

The honest cost of maintenance mode is different, and slower. Bugs that aren’t security bugs tend to stay. Plugin authors drift toward wherever the users are going. Third-party sync and integrations get tested against the new version first. None of that hurts in month one. It compounds over a couple of years.

What the database version changes

The headline change is the storage layer, and it changes more than it sounds like it does. The database version stores your graph in SQLite, not in a folder of Markdown files. Markdown export is planned but the team hasn’t committed to continuous two-way sync with files, and the community FAQ is direct about the consequence: the database is canonical. You can’t change your graph by editing an exported file the way you can today.

For a lot of Logseq users that single fact decides it. “My notes are just Markdown files in a folder I control” was never a feature bullet, it was the whole reason to pick a local-first outliner over a hosted one. If that’s you, the database version is a different product wearing the same name, and no amount of speed improvement buys back the property you actually wanted.

What you get in exchange is real:

• Performance at scale. Queries and linked references are meaningfully faster, and graphs in the 50k+ page range are a supported case rather than a horror story.
• End-to-end encrypted sync. Your data encrypts locally with your password before it goes to the server, and decrypts on the other device.
• Real-time collaboration, which the file version could never do properly.
• Active development. Every new feature from here lands in this version and only this version.

And the sharp edges, as of the beta:

• Sync and RTC require a Logseq Pro subscription. A self-hosted sync option is in development as the free alternative, but it isn’t the thing you get on day one.
• Mobile is behind the desktop. iOS ships through TestFlight, Android through nightly builds, and you can’t run the new mobile app and the OG mobile app on the same device at the same time.
• Whiteboards are gone for now, and Zotero support moved to community plugins.
• Import is not a clean copy. There’s a Markdown graph import tool, but hashtags and page references behave differently in the database version. The FAQ’s own advice is to play with the new app before you import your old data, which is good advice and slightly ominous advice at the same time.
• It’s a beta. The team recommends automated backups because data loss is possible. Take that literally.

Picking

Here’s the decision, without hedging.

Stay on OG if your graph is mature, your workflow is muscle memory, and the plain-files property is load-bearing for you. A frozen tool that does the job is worth more than an improving tool that does a slightly different job. Set a calendar reminder for six months out to check whether the DB version has landed stable Markdown export, and get on with your life until then.

Move to the database version if you’re on Logseq for the PKM machinery rather than the file format. Backlinks, queries, a big graph, sync across three devices. That’s the workflow the new version is built to serve, and staying on OG means watching it stop improving. Import onto a copy, run both for a month, and only then commit.

Wait if you want the DB version but not the beta. Nothing bad happens while you wait. OG isn’t going anywhere and the import tool will only get better. Just pick a date to re-evaluate instead of drifting for a year.

The one answer that isn’t on the list: agonizing. This is a reversible decision in both directions, and the anxiety is costing more than the choice is worth.

The third door

There’s a group this framing doesn’t serve, and it’s bigger than it looks. Plenty of people came to Logseq for the outline itself. Fast nesting, everything in one tree, capture a thought without deciding where it lives first. The queries and the graph view were things they admired more than used.

If that’s you, the OG-versus-DB question is a fight over machinery you were never really running. And picking a side of it means either a frozen app or a beta migration, both in service of features you’d have to be honest about barely touching.

listlis is built for that group. One tree, keyboard-first, no version to choose. A node is a title plus an optional Markdown body, so a line stays scannable until it needs room. The loop runs entirely from the home row: o adds a sibling below, Tab nests it under the row above, Shift-Tab pulls it back out, ! makes a node a todo, c completes it. Completion carries the subtree and rolls up to the root, so a finished branch reads as finished. / searches every node by title and body. Reordering is cheap because sibling order is a fractional index between neighbors, which means reparenting a whole subtree writes one row instead of renumbering a list.

The thing that tends to land with Logseq people is the query replacement. listlis exposes your tree to AI assistants over MCP, so you ask for the slice you want in plain language: pull everything about a project, tell me what’s due, drop this into the right branch. No query syntax, no per-node AI credits metered against you, no chatbot bolted into the sidebar. Getting the right slice of your own thinking back out was what queries were for. This does that job with less machinery in the way.

What listlis doesn’t do is reproduce Logseq’s datalog query engine or its backlink graph. If those are genuinely how you work, stay in the Logseq family and pick OG or DB on the terms above. Fit matters more than a pitch.

Where to go from here

If you’ve decided to leave, the calm guide to leaving Logseq walks the options one at a time, including the ones that aren’t us. If you’re comparing outliners more broadly, the comparison hub maps where each tool draws its line, and Workflowy vs Logseq covers the same ground from the other direction.

And if the third door is the one you want, open a root at app.listlis.com and start typing. Bring an OPML or Markdown outline from the import panel, or start with an empty root. No template gallery, no version to pick.