r/logseq

In a service like Notion, there is a clear danger. If the service got hacked or went bankrupt, I could lose my data. (although it's almost 0% probability) Or there may be a danger that some Notion employee could steal my data. (if data was not encrypted)

Arguing a danger like this makes sense, and should be considered.
Logseq and Obsidian resolve this issue by "storing all data locally"; this is it.

In Logseq, there's no reason the data should be stored as easily readable raw data (like Markdown) for this issue. If we have enough ways to export data, we don't have to care what format it's stored in. Because "we own the data".

I don't understand why people are obsessed with 'Markdown'. This is an open-source project. Even if the whole team just died tomorrow, we can find a way to get our data back.

Of course, it would be great if we had both performance and Markdown format, but Logseq doesn't fit with Markdown.

Saying “the team should maintain Logseq OG because of Markdown format support” is totally absurd.

I tried to leave Logseq for Obsidian. Here's my soapbox.

When the DB version dropped, I found myself standing at a crossroads.

Full confession: I'm a chronic greener-grass gazer. I'm always leaning over the fence, eyeing whatever shiny new tool just showed up. I've been tempted by Tana, ogled Obsidian, rendezvoused with Roam, hovered over Heptabase, courted Capacities, and nibbled at Notion.

So when DB arrived and I realized I didn't want to stay on a version that would be maintained but never really updated, I knew I'd have to put real work into getting DB set up the way I had things in Markdown. And I figured, if I'm already paying the migration tax, why not shop around a little before I sink my time into DB?

The siren song

I read the posts. So many posts. Frustrations with the team, the update pace, the leadership, the bugs. And the advice was always some version of: spend a little time in Obsidian, let AI help you migrate, install the right plugins, and voilà, it'll feel just like Logseq.

Friends, that is a lie, possibly forged in the fiery pits below. It cost me hours of work, and yes, I'm being dramatic on purpose, because I've never been more certain of anything:

Logseq is the best note-taking system out there, and I want the world to know. Those of us who have tasted the Logseq light, let us not wander into the Obsidian darkness.

Block-first, non-linear thinking is the way. It's the closest thing to how the brain actually works. I shouldn't have to decide up front what's a page and what's a block. Seeds should grow into plants, and plants should drop new seeds. That's basic fabric-of-the-universe stuff. Storing ideas at a tiny, granular level is exactly what makes them so useful when I zoom out.

Trying to get Obsidian to think in block references felt like jamming a square peg into a round hole. Using blocks across my whole database was nearly impossible, and it only "works" if your definition of working includes enjoying a steaming plate of dog poop. (I don't cuss, but moments like this make me wish I did.)

Context on me and how I use Logseq

I'm a writer. My ideas don't live in folders; they live in conversation with each other. I need to reference blocks endlessly, see which older pieces inspired what I'm writing now, and cite sources constantly (a lot of them flowing in from Readwise). Logseq lets me write beneath other writing and wander into topics beneath topics, until my notes start to feel like an extension of my own head.

Brains don't think in hierarchies. They think in connections. I want my notes to do the same.

On "but I want to write in prose"

Writing in blocks has actually made me a clearer thinker. It keeps nudging me with one question: what exactly am I trying to say in this block? And underneath it, I can tuck the supporting stuff, the evidence, the tangents, the half-formed thoughts. They don't need to be referenced anywhere. They can stay folded away. But the day I want them, they're right there waiting for me.

And if you want it to look like prose, one plugin will do that. On the surface it reads like an essay; underneath, it's still built the way I think, in small ideas I can reference and expand on later.

The headless hill I'll happily stand on

Now that headless setups exist and AI makes building visual plugins so easy, I've come around to this: pick the system with the strongest structure and database underneath, then shape the interface on top. I'd rather have a backend that can track, tag, and categorize down to the block than trade that away for a slightly prettier screen I could probably recreate in Logseq with a plugin or two.

The one complaint I get

A lot of the frustration I see is about slowness, which honestly surprises me because I've never run into it. For context, I have about 40,000 blocks, 1,300 pages, 200 tags, and just over a million words, and neither the MD nor the DB version has ever lagged for me (I also do use Sync). Maybe my graph is small compared to others, so I'm genuinely curious: if you've hit slowness, how big was your database when it started?

I also understand not wanting to leave Markdown. For me it just doesn't matter much. In the age of AI, my notes are as easy to get at in SQL as they ever were in MD.

Anyway, thank you for coming to my soapbox. I genuinely welcome anyone who wants to prove me wrong. And before you ask: yes, I installed every plugin people recommend for Logseq-to-Obsidian switchers. Outliner, Zoom, Block Link Plus, Hover Editor, Templater, Excalidraw, Journals, Calendar, Bases, Heatmap Calendar, Homepage, Dataview, Omnisearch, Strange New Worlds, Advanced URI, Shell Commands, Front Matter Title, Iconize, Hider, Daily Notes Editor, Better Search Views, Natural Language Dates, Tasks, Sync Embeds, Zettelkasten, and probably a few I've already blocked from memory.

It still felt miserable.

So I'm packing up my blocks and heading home.

As someone who used Logseq OG for quite a while and later moved to Logseq DB, I’ve been wondering why the Logseq team chose not to formally end support for the old version and focus entirely on the new one.

I understand that, in practice, the team is already putting most of its development effort into Logseq DB. But I think there is still a very significant difference between developing DB while continuing to maintain two versions and officially ending one version and concentrating the whole project around DB.

The main reason I think this matters is the community.

For a project like Logseq, I believe the user community is not just an audience for the software, but a major part of the product ecosystem itself. It consists of thousands of people who share workflows and methodologies, write documentation and tutorials, build plugins and themes, answer questions, report bugs, contribute code, and generally create the knowledge and infrastructure around the application.

In that sense, a healthy community can sometimes be almost as important as the core development team.

Obsidian is an interesting example. Despite competing with note-taking products backed by much larger companies and vastly greater resources, it managed to build an extremely strong position in the PKM space. I think its community ecosystem, including plugins, themes, workflows, tutorials, discussions, and the enormous amount of accumulated knowledge around the product, was one of the major reasons for that success.

This is why I worry about Logseq maintaining OG and DB at the same time.

Logseq OG and Logseq DB may share the same name, philosophy, and many surface-level features, but technologically and behaviorally they are increasingly becoming two different applications.

That creates a kind of community fragmentation.

A tutorial written for OG may no longer apply to DB. A plugin built for OG may not work on DB. Discussions about workflows become filled with questions about which version someone is using. Developers have to decide which platform to target. New users encounter documentation and advice written for two different generations of the application.

Over time, this makes it much harder for a single, coherent Logseq community to form around the product.

And I think this is potentially more damaging than the engineering cost of maintaining two codebases itself.

If this problem is not resolved, I worry that Logseq may eventually reach a point where one of the two versions has to be abandoned anyway. But by then, the community may already have been split for years, with plugins, documentation, workflows, and users distributed across two ecosystems.

From that perspective, it might be worth seriously considering a more decisive long-term strategy.

For example, perhaps the team could try to bring the two versions closer together. They would not necessarily need to become technically identical, but they could be made compatible enough that a single community ecosystem could realistically support both.

Or perhaps we will eventually need something ridiculous like Logseq OGDB that somehow combines the two. :)

Alternatively, the project may eventually have to make the difficult decision to officially discontinue one version and establish the other as the clear future of Logseq.

I imported old logseq og notes, that contained asset links in pages into the new db logseq and tried to export it.

I was disappointed the export just dumps all the markdown files in one folder. The export didn't put pages in a pages folder and assets in an asset folder and journal files in the journal folder. In fact the assets are not exported at all, for the markdown export

The export should try its best to preserve the logseq graph format as best as possible.

This means, if it continue writing my notes in Logseq-db It will be very difficult to go back to logseq-OG or a logseq-OG compatible app.

People have said SQLite is not opaque format. But in order to export, you need to understand their schema and how they structure their data.

It would be nice if their export tried to preserve the logseq md graph format. So:

Logseq MD -> Logseq DB -> Logseq MD (export)

I also tried the mirror mode, however I noticed random pages had missing data...
So the mirror mode didn't work for me.

It looks like some pages didn't import for me, which could explain the missing data. I might have to consider alternatives to logseq. Because I really want the MCP feature for logseq-OG

Hey I've been using loseq for my medical studies for quite a while now last month i switched to the db version and it's killing me it's lagging a loooot some plugins like save scrollbar , also the links problem it gets duplicate a lot even tho it has the exact same name one is empty and the other has my content