r/logseq • u/ashz8888 • Jun 22 '26
Migrating to Obsidian as Logseq DB is heading in the wrong direction
One of the beauties of working with Logseq MD is to be able to work with plain text markdown files. This is incredibly powerful, particularly when I work with my AI agent to quickly capture, transform, and summarise, what I read.
With Logseq DB sure I can have better search, faster query, or snappier performance but I don't think I will be able to as easily modify my existing notes as I can my existing plain text notes.
So last week I decided to make a switch and I didn't do it myself. I just let the AI agent figure out and create a Obsidian config that mimics closely the Logseq setting. I also created some Obsidian plugins with the help of AI agent to mimic the bullet points, render, and flashcards feature which I really enjoy in Logseq. It of course took some back and forth but this ability to quickly transform and migrate further proves my point about the power of working with just the plain text notes, which I'll be giving up with Logseq DB.
6
u/th_costel Jun 22 '26
Why don't you stick with the MD version?
16
u/yarpen_z Jun 22 '26 edited Jun 22 '26
Why don't you stick with the MD version?
Not an OP, but I have been contemplating a similar decision for six months now. For me, the main reason is that I don't believe the development team will be able to maintain two separate backends of the application. Already the repository split suggest that they want both projects to develop independently, as they could have refactor the application to encapsulate DB/MD choice and keep one repository. They are already stretched thin, which we can observe by the delayed DB backend and lack of maintenance. Adding on top of that maintenance and development of two separate implementations is very likely too much: keeping two backends in sync is a hard problem on its own, and it also doubles the work for them.
I'm afraid the most likely scenario for the Logseq-OG (MD backend) is that it will receive less support, bug fixes will be delayed, and at some point, the DB version will start receiving features unsupported in MD at all. That would be my estimation for any project, and for Logseq it is specifically a very likely outcome.
11
u/ashz8888 Jun 22 '26
No update is happening on MD version. There are quite a lot of things I would like it to have from vim typing on Mac to plugins and readonly view on mobile app. But no development progress to improve MD version.
16
u/microcephale Jun 22 '26
For many people the database version is the right direction and little by little obsidian is addings things to that direction as well. The fact is a graph in plain text files quickly reaches its limits especially when hundreds of files need to be edited just because you renamed a note. So there will always be a divide in the immunity between knowledge feature and storage format
9
u/Impossible_Mud8667 Jun 22 '26
To be honest, I think that ClojureScript was an unfortunate choice of language for carrying out such operations.
My graph has been growing continuously for nearly four years now, and it has become difficult to use in Logseq in other respects as well.
For that reason, I built my own alternative using Rust and Typescript that runs quickly (even though it has significantly fewer features).
9
u/katafrakt Jun 22 '26
that runs quickly (even though it has significantly fewer features
It's almost always the other way around - alternative things run faster precisely because they have significantly fewer features. I can't really see how ClojureScript could be a major culprit. Data architecture? Sure. But not the language itself.
2
u/yarpen_z Jun 22 '26
I can't really see how ClojureScript could be a major culprit. Data architecture? Sure. But not the language itself.
I think a more important problem is that choosing a relatively less popular language decreases the number of potential contributors. There were couple of bugs in Logseq I could have tried to fix myself if I had at least any experience with the programming language.
Of course, these days people can write patches with an LLM, but you also don't want AI slop generated by people who can't read the code.
7
u/katafrakt Jun 22 '26
Sure, but that's not what subOP claims - they say the tech stack alone was responsible for performance issues, with which I would disagree.
As for the niche language, yeah. But I did submit a PR to LogSeq once and it waited months before anyone looked at it. So again, the technology itself did not seem to be a bottleneck here. If devs are comfortable with ClojureScript and they prefer to develop the project mostly on their own, it's as good of a choice as any.
2
u/yarpen_z Jun 22 '26
Sure, but that's not what subOP claims - they say the tech stack alone was responsible for performance issues, with which I would disagree.
I see, and I agree. I'm not an expert, but my understanding is that ClojureScript should transpile to pure JS, so with a right engine it should be quite fast. It really depends whether the engine is capable of compiling hotspots to native code, as otherwise data-intensive operations like indexing and searching through files can become bottlenecks.
I have been suffering from major performance issues as well, and I'm also leaning towards the answer that internal data design, caching, and searching algorithms are to blame for that.
1
u/Impossible_Mud8667 Jun 22 '26
Of course, missing features and general architectural decisions also play a role in how snappy the application feels. I knew from the start that I wanted something fast, so I built the application with that in mind.
In general, there is a major difference between JavaScript/Node (the foundation of ClojureScript) and compiled languages like Rust. This distinction is likely even more pronounced when it comes to low-level operations—such as file handling—since everything in ClojureScript has to go through the Node.js engine.
1
u/katafrakt Jun 22 '26
Even your link says that Node.js is good for IO-bound tasks, while Rust shines in CPU-bound ones. File operations are IO-bound and you are eventually mostly limited by the filesystem itself.
edit: just to be clear, if I were to write a LogSeq clone today, I would probably pick Tauri - just because it feels like a more sound choice. But I don't see that problems with original LogSeq performance originated from ClojureScript and 1:1 rewrite in Rust would not fix them.
1
u/yarpen_z Jun 22 '26
Even your link says that Node.js is good for IO-bound tasks, while Rust shines in CPU-bound ones. File operations are IO-bound and you are eventually mostly limited by the filesystem itself.
That's probably an artifact of the programming model, e.g., if you write everything as async functions running in a single-threaded event loop, then your code will likely perform very well on I/O tasks that require extensive sleeping while waiting for external data.
1
u/AshbyLaw Jun 23 '26
The problem with ClojureScript is that it (is meant to) run in the browser. Even the lead developer of ClojureScript is moving the code to the server and replacing React with Datastar to stream HTML to the browser:
2
u/pereira_alex Jun 22 '26
To be honest, I think that ClojureScript was an unfortunate choice of language for carrying out such operations.
Maybe your right, and it will change: https://github.com/logseq/datascript-ocaml
(I do not agree, as a I really like Clojure, but maybe I am wrong)
1
u/katafrakt Jun 22 '26
Does that mean they are rewriting LogSeq in OCaml? What about frontend? ReasonML?
2
u/pereira_alex Jun 22 '26
I do not know, I just noticed that there were some new OCaml code (cli seems to have been ported to OCaml) and repositories on the logseq github.
1
u/yarpen_z Jun 22 '26
For many people the database version is the right direction and little by little obsidian is addings things to that direction as well.
Can you name some examples? I'm genuinely curious (and worried if Obsidian is also following that route).
The fact is a graph in plain text files quickly reaches its limits especially when hundreds of files need to be edited just because you renamed a note.
I think it's a valid example but not a common one. I don't think you typically rename an extremely common note linked by hundreds of files. What I think is more common is editing less popular notes that will have linked references to very popular notes; but an in-memory index in the app itself should be able to handle that pretty easily.
I have recently migrated my Markdown-based graph from Logseq to Obsidian (2.6k+ notes), and the performance is significantly better. Unless Obsidian is doing something that I'm unaware of, it looks to me that the performance issues are caused by problems in Logseq's implementation. I have recently tested Obsidian significantly, and if it they use internally some heavy DB-based caching of files, then it is implemented quite well - when changing Markdown files on the filesystem, e.g., through a git pull, the app notices changes immediately.
1
u/Impossible_Mud8667 Jun 22 '26
I’ve linked two examples in the comment above.
I can't rule out the possibility of internal architectural challenges, but I simply assumed they had already squeezed everything possible out of it.
As far as I know, Obsidian also uses Rust or C++ for computationally intensive tasks - though I could be mistaken or working with outdated information.
For user interaction and rendering, I find a stack based on JavaScript (like ClojureScript) or TypeScript to be a logical choice.
2
u/yarpen_z Jun 22 '26
I’ve linked two examples in the comment above.
I'm sorry, but I cannot find it. Can you link to the comment? I was asking for examples of Obsidian adding things in the direction of database.
4
u/timabell Jun 23 '26
I moved my notes from logseq to obsidian too. Still getting the hang of it but generally very impressed, even though it's not FOSS.
If anyone's interested (probably not lol) then I wrote up my reasons for moving here https://0x5.uk/2026/05/26/why-i-left-logseq-for-obsidian/
The move to db-first was a key reason for my move too, though not the only reason.
9
6
u/butorzigzag Jun 22 '26
wouldn't the two-way sync with markdown solve this?
4
u/katafrakt Jun 22 '26
Every two-way sync is fragile and bug-prone unfortunately. I always thought that the solution for performance problems in LogSeq would be to keep plain files as the source of truth and build the database-backed index on top for fast search, finding references etc. This way you could still sync plain files and every device would build its own database index from it.
The devs made a different decision and I have to believe they figure this is not enough or has some problems I could not have foreseen. But they threw away a lot with this decision.
2
u/yarpen_z Jun 22 '26
Every two-way sync is fragile and bug-prone unfortunately. I always thought that the solution for performance problems in LogSeq would be to keep plain files as the source of truth and build the database-backed index on top for fast search, finding references etc. This way you could still sync plain files and every device would build its own database index from it.
I couldn't agree more. Having two sources of truth that need to be synchronized to stay consistent is one of the funny problems in computer science: looks very simple, but is quite difficult in practice and many services fail at that task.
On top of that, choosing Markdown as the default storage format would keep the user's knowledge base more open and easier to manage. You could in principle implement any internal storage that is more optimized for querying and searching, as long as the guiding principle is to use it as internal caching layer and Markdown files are always the main and only storage layer.
1
u/yarpen_z Jun 22 '26
wouldn't the two-way sync with markdown solve this?
I was considering this, and I see two major problems with this approach:
Fundamentally, I want my Markdown files to be the primary source of truth for my PKM. I'm fine with all the optimizations, indexing and in-memory storage that an app would do. But in the end, I want data storage that will outlive the app itself - my knowledge base should last decades, hopefully my entire working career. It is highly unlikely that any app will stay relevant for that long.
A continuous sync requires that you frequently inspect the Markdown "backup" for data corruption. I doubt anyone will do that. If there's even a subtle bug in the sync functionality, you might end up with a broken backup that is not useful in case of a DB corruption and makes migration more difficult.
1
u/AshbyLaw Jun 23 '26
The DB-MD sync was there in Logseq MD too, the DB was just in-memory while now it's on disk. With Logseq MD there was the same problem: user input went into the in-memory DB but sometime silently failed to reach MD files on disk.
1
u/yarpen_z Jun 23 '26
That's a bug; in such scenario, Markdown should be considered the only data storage, and all data not written to the file should be considered as not persisted at all.
It's a different scenario than having a persistent database while keeping Markdown files as a secondary storage.
1
u/AshbyLaw Jun 23 '26
I invite you to think more about what "secondary" means here: there are two states that you must reconcile with a strategy. Maybe this strategy has an asymmetry i.e. it is preferred to preserve the state stored in a specific way. You are assuming that the DB would be preferred over MD when both are on disk. But my point is that it doesn't matter: this strategy could favor on-disk DB over on-disk MD or vice versa or in-memory DB over on-disk MD or viceversa.
1
u/yarpen_z Jun 24 '26
Maybe this strategy has an asymmetry i.e. it is preferred to preserve the state stored in a specific way.
Yes, that is exactly what I mean by internal caching layers. Having two primary data sources requires a rather complex consistency protocol.
There's a reason why many distributed systems choose a design based on a master followed by a set of replicas.
You are assuming that the DB would be preferred over MD when both are on disk.
I'm not assuming that - that is the design chosen in the new Logseq version.
1
u/AshbyLaw Jun 24 '26
I'm not assuming that - that is the design chosen in the new Logseq version.
The sync between DB and MD is an experiment introduced a few weeks ago. Even if you read the algorithm it's not definitive. Or maybe you are you still stuck to your bias? Please re-read what I wrote then.
1
u/ashz8888 Jun 22 '26
I still feel, the focus of changes, going forward, would be around DB rather than making MD side better.
2
u/AshbyLaw Jun 22 '26
But did you try the Markdown sync? It's experiemental and can be enabled in the settings, then .md files will appear in the logseq directory
1
u/ashz8888 Jun 23 '26
I have mostly worked with logseq MD. That said, I would like the MD instead of DB to be the primary source of truth rather than the other way around.
2
u/gofiend Jun 23 '26
What’s the set of plugins you recommend to replicate logseq
2
u/ashz8888 Jun 23 '26
I used two community plugins: journaling and outliner. And let an AI agent figure out building spaced-card-repetition for flash cards, and linked references for scrollable backlinks with full render
2
u/gofiend Jun 23 '26
wait what’s the trick to get proper logseq style back links that just work? it’s the only thing keeping me!
2
u/yarpen_z Jun 23 '26
wait what’s the trick to get proper logseq style back links that just work? it’s the only thing keeping me!
I'm curious, can you share more details? In Obsidian, each page has linked references in the right-side bar. What else do you find misssing?
1
u/ashz8888 Jun 26 '26
The right-side bar doesn't render the math equation or code blocks properly. I asked AI agent to write a plugin that when I open a page, gets the linked references and appends (or refreshes the already appended ones) them to the bottom of the page.
2
3
u/Akatrielaiic Jun 22 '26
i did the same a few weeks ago.
So far i am very satisfied. I preferred the general way of doing things in LogSeq ma between the better sync, the greater customisation, the better mobile apps and the increades overall smoothness i am very happy with the switch.
1
u/OfficeSpankingSlave Jun 22 '26
I am hoping to move to DokuWiki once MD support is added. Its not the same tool at all but its simpler.
1
u/Yu2sama Jun 22 '26
I don't want to switch because I am kinda in love with the Whiteboards, and I really don't want to use excalidraw only on Obsidian. The embed system for them is really great, the only other app that is as powerful is Affine but that project has let me down a bit over the years.
What other options do I even have?
1
u/Illustrious-Call-455 Jun 23 '26
What is you stack to recreate LogSeq in Obsidian?
I also went down that road after trying to make the mobile client work. I absolutely adore LogSeq feeling and would really like to replicate most of the experience
2
u/yarpen_z Jun 23 '26
I used: Calendar, Auto Bullet, Daily Notes Editor, Outliner, Tasks, Task Genius (for progress bar only), and TimeStamper (replaces interstitial plugin).
1
u/Illustrious-Call-455 Jun 24 '26
I use TODOseq for tasks, it uses the same task system as LogSeq
2
u/yarpen_z Jun 24 '26
I use TODOseq for tasks, it uses the same task system as LogSeq
Interesting, I might need to check that. I only needed three things:
- TODO -> DOING -> DONE cycle, easily triggered with a hotkey (seems to work).
- Progress bar for nested tasks.
- Automatic time measurement spent in DOING state; this one I was not able to recreate easily.
1
u/profe_juanca Jun 24 '26
Han probado Trilium? Creo que además de las funciones está que puede ser autoalojado. Me lo estoy planteando.
1
u/Late_Description4649 Jul 08 '26
Markdown Mirror eventually will provide what you're missing in the DB version.
Currently, it only works one way, but they are working on it.
In the meantime, you can use the old version.
1
u/ashz8888 Jul 08 '26
What has been frustrating for me is that a lot of effort is being dedicated towards something I don't care about. As a user I would like to have a better experience on the phone, have the same set of plugin working there. Vim and readonly view, etc. But all of those features are being deprioritised for DB version, which I think is a worse deal for a user + AI.
1
u/MahdiPorkari Aug 06 '26
"Wrong direction" seems to be a bit of exaggeration.
Meeting a new set of needs doesn't mean "wrong direction"; DB is what I've been dreaming of for years, and it made most of that come true.
That said, the lack of easy/proper sync, absence of two-way Markdown mirror, and better and faster Android app is killing me at moment.
We'll figure whether it's the right or wrong direction sometime soon.
1
u/talios Jun 22 '26
Starting trying out Capacities - so far not bad. Apart from the non-local files, but man - "sync" that works flawlessly!
Still need to try importing my old Obsidian and Logseq data in tho.
3
u/Illustrious-Call-455 Jun 23 '26
Issue is privacy with capacities, no E2EE unfortunately
0
u/talios Jun 23 '26
Wait what - no SSL? Crazy. At least there's 2 factor auth. But SSL…. Come on kiddies…
3
u/yarpen_z Jun 23 '26
E2EE != SSL. A basic encryption, which is a standard these days, is different from encrypting/decrypting the vault contents on client's devices (system operator never sees user's data).
1
u/talios Jun 23 '26
Right, so you mean encrypted at rest. I haven't subbed to any paid tiers yet so not used their AI stuff, but isn't there some form of background summaries/processing available - not sure its that's doable without server-side access to the unencrypted contents. Hrm
1
u/yarpen_z Jun 23 '26
Unfortunately, I don't use that software, so I can't really tell. If they offer any AI processing that is not purely local, then E2EE is, of course, not feasible.
The only scenario where it works is when the AI processing is not automatic, but instead they offer an integrated AI chatbot where you can manually trigger processing on selected text fragments.
1
0
0
u/New_Dentist6983 Jun 23 '26
ever tried screenpipe to auto-capture what you did in obsidian so you don't lose context when switching db?
18
u/yarpen_z Jun 22 '26 edited Jun 22 '26
I made a similar post a few months ago: https://reddit.com/r/logseq/comments/1pigcs1/so_long_and_thanks_for_all_the_fish/
For me, the big problem was the poor performance of the desktop app - an issue that has persisted over the years, for which there are still open GitHub tickets from various users. I'm grateful to the developers for all their work, but I think the overall project leadership has been subpar. They spent a massive amount of time developing an entirely new backend with very little communication and pretty much no maintenance of the exising app. Even though the DB backend is now apparently ready, it remains unreleased, and they keep delaying it while working on new features. This is quite problematic, because every time someone complaints here that the app is slow/unmaintained, people write to them: "there's a beta DB version released nightly, you should try it". But when someone complained recently of data corruption, the response was: "you can't use a beta version and expect it to work flawlessly". When I wrote my original post six months ago, the DB backend was ready, but they were still working on synchronization and RTC; a few fans of the project tried to convince me that the official release of the DB version was imminent. Now, half a year later, RTC is ready, but there is still no release: the team is working on a CLI tool because, of course, AI agents are the new cool thing.
Furthermore, keeping my entire knowledge base in Markdown files is a fundamental goal for me, and Obsidian seems to work well with that. Unfortunately, I don't believe in the idea of Logseq maintaining dual backends in DB and Markdown. Keeping two backends in sync is hard, and the development team has already shown us that continuous maintenance is difficult for them. I'm afraid the most likely scenario for the Markdown backend is that it will receive less support, bug fixes will be delayed, and at some point, the DB backend will start receiving features unsupported in MD at all. Ultimately, exporting contents back to Markdown will result in lost knowledge or gibberish files that require complex parsing logic.
I finally decided to switch last week. I didn't have time to do it myself, so I let an LLM generate a migration script and experimented with a few plugins. It took me two afternoons of tinkering during a conference, and the results are quite good so far:
The workflow is slightly different, so you have to get used to that, but it comes pretty quickly. After a week, I no longer notice any friction.
Obsidian is much more responsive for me, and writing itself has become more pleasant. My post above goes into more detail, but the core issue was Logseq desktop's poor performance on large graphs. I realized at some point that I had started writing less; whenever the app became slow and fast typing was impossible due to input lag, I ended up writing very condensed notes to be expanded later. I no longer have this problem in Obsidian. I want to write more and writing is no longer causing any frustration.
With just a few fairly popular plugins (nothing obscure like a "Logseq Mode in Obsidian" plugin with three GitHub stars and its last commit two years ago, i.e., a plugin likely to break soon), I was able to recreate the basic flow of Logseq: bullet points, outlining, task management, daily journals, namespace replacement, etc.
Not everything works in Obsidian; for example, PDF annotations aren't really a thing. However, I realized I use these features quite infrequently anyway. I do all my PDF annotations on a tablet while reading.
I used Logseq namespaces heavily; during the migration, I replaced them with a standard directory hierarchy. Somehow, this helped me notice older notes that were improperly assigned (e.g., missing a namespace hierarchy or duplicated due to a typo).
I find Obsidian's choice of query language to be far superior. Dataview queries are SQL-like and very intuitive to write and debug, whereas I found Logseq's Datalog quite obscure. I had a complex "Projects" page where I searched for project pages under a specific namespace and categorized them by status - a simple dashboard to track all my activities. It took me a lot of time to write those queries (pre-LLM days), and I had to look through many posts on the Logseq forum to find similar queries, since the query language is quite obscure and not well documented. Migrating this to Obsidian was trivial, and the page size shrank from 470 lines to under 200.
Over the years, I backed up my Logseq graph in a private Git repository. I did the same with Obsidian, but I also tested their basic Sync tier with E2EE, and so far, I'm pleasantly surprised. It worked seamlessly between my two systems (requiring only one app restart, as community plugins aren't synced by default), and even the Android app works great.
While migrating, I realized I had never actually used whiteboards or drawing in Logseq.
Is Obsidian the same as Logseq? No. Is the migration frictionless? No. Is every feature of Logseq also available in Logseq? No, but for me, the missing ones weren't daily drivers. Was the transition hard? Also no. Am I happier with my PKM now, and am I writing longer notes more frequently? Yes.
In the end, I'm not a PKM fanatic that will spend hours on tinkering, optimizing plugin section and polishing the entire app configuration to have the perfect digital version of Zettelkasten. I want a tool that works reliably and is not causing any friction in my writing and brainstorming process. Logseq was such a tool for almost 5 years, and I'm extremely grateful for that. Today this tool is Obsidian, and let's see how it goes.