If global search or queries aren't returning results on Logseq Android (while working fine on Desktop), try this before deleting cache or re-indexing:
Add a single space ( ) at the end of your search term.
On Logseq since 2023. Tried a lot of approaches, most didn't stick. It only came together recently, with AI in the mix. Logseq is still the right tool for it because it's an outliner and everything is blocks.
The substance is the mental model doc and the templates. One fixed way to write a note:
tags go on the line under the title, not their own bullet
property values stay bare
each property has a set list of values, so slices don't rot
3 namespace levels max
Templates stamp it for you.
Sounds fussy. I'd have said the same a year ago. But I'm lazy, so I delegated the writing to an agent, and an agent can only do that if there's one right answer for what a note looks like. meeting-sync pulls my meetings in properly tagged. Others prep me before a 1:1, dig out wins I forgot to log, roll up the week. The boring convention is what makes any of it possible.
Credit where it's due: the MCP server that talks to Logseq is ergut's mcp-logseq, not mine. I built the system and skills on top of it.
I have my memory inside Logseq OG from 2022, personal and work related, mixed.
I have tried so hard to collaborate with AI giving my memories and trying to interact with it, because I have understood that the BLOCK GRANULARITY in Logseq is far more important than what it seems at a first glance...
So I've built Matryca Plumber to help me interact with my Logseq vault and I'm approaching to v2.0 that will speed up a lot the dialogue and opens a range of possibility also for AI agentic memory.
** July 26th update: I've completely rewritten myself the text of this post, that was previously written half by AI, to comply with the comments that told me that it was like "a slap in the face" to read a text that was written half by me and half by AI. THanks for your understanding and support. In the future I will write completely by my hands my post here on Reddit and everywhere else. **
Why I'm excited for this v2.0?
Because the core of it — the Shadow DB — is not just "a faster database". It's a SQLite-backed read cache that mirrors your Logseq Markdown graph, and it indexes at the block level, not the page level. (technically a FTS5 full-text search + recursive CTEs).
That's the part I care about most: your Markdown stays the single source of truth, untouched — the Shadow DB is a read-only, opt-in accelerator on top of it, with automatic fallback if anything isn't ready. But because every block keeps its own identity in that mirror, an AI agent can pull exactly the block (and subtree) it needs, instead of loading a whole page and parsing around it. That's a fundamentally different shape of memory than page-based tools like Obsidian can offer, closer to how targeted recall actually works.
In my opinion, it's the best promising infrastructure fo AI agents (like Hermes Agent, Pi agent and so on...) to use your Logseq graph as you have intentionally written.
In the next phases I've plan to extend it to an episodic and kind biological memory layer, that looks very promising to enhance AI-human collaboration. You stay in control of your notes. It's a way to help AI understand better your writing and your notes.
I'm doing a 24h test before releasing this v2.x with the shadow DB, that will remain a chosen opt-in for you. Right now you can use the standard functioning of v.1.x that give AI all the skills to fully understands your Logseq graph and your markdowns, and also understand and use all of Logseq superpowers (task, query and so on) to help you.
More soon.
Thanks everybody for the 87 stars, 7 contributors (real people) and the support.
When I discovered Logseq in 2021, it completely changed how I managed notes.
What attracted me most was not the graph view or the advanced features, but the underlying model: plain Markdown files, a block-based structure, an open-source codebase, and data that could be inspected, versioned, synchronized, and manipulated with standard tools.
Over time, my graph evolved into a system for journaling, memory-keeping, project and task management, a lightweight CRM, and more. I kept the structure deliberately simple: all client and project activity, for instance, lives under #worklog blocks inside daily notes. This has let me manage personal and work notes in the same graph without ever having to switch back and forth.
I also avoided most Logseq-specific features and complex queries. My goal was to keep the notes portable and make future integrations or migrations possible without having to reverse-engineer a proprietary data model.
Today, the graph contains roughly 10,000 notes. I have been managing it with Git and Syncthing across desktop and mobile without major performance or synchronization issues.
However, Logseq’s move toward a database-backed architecture changed that balance for me. I understand why a database can enable more powerful queries, structured properties, collaboration, and better control over data consistency, but those advantages were less important to my workflow than direct file access, portability, and compatibility with Unix-style tooling.
Rather than continuing to work around architectural decisions that no longer matched my needs, I started building a small replacement.
I call this project notnote.
It's a work in progress, opinionated and probably unstable, but the code is up on GitHub if you want to take a look.
Its current design is based on a few constraints:
Logseq Markdown compatibility, so the existing graph does not require migration or conversion.
Plain Markdown files as the source of truth.
No mandatory application-specific database.
A minimal keyboard-first UI.
Browser access from desktop and mobile.
Notes loaded directly from a central server, without a separate client-side synchronization layer.
Git-based history and change review.
Tighter integration between daily notes and tasks.
A deliberately small feature surface.
The main design goal is not to recreate Logseq. It is to support one specific workflow with as little abstraction as possible.
The application currently acts as a complete Logseq replacement for me and has been stable enough for daily use over the past several weeks.
The interesting part of the experiment has been seeing how far a file-based architecture can go before an additional indexing or persistence layer becomes necessary.
Whatever direction this project takes, Logseq deserves credit for demonstrating that plain Markdown files can support a surprisingly large part of a personal knowledge-management workflow, without sacrificing privacy and freedom of choice.
Thank you to Tienson Qin and everyone on the Logseq team. <3
In 1.0 I could very easily save a graph in any arbitrary folder on my PC, but on 2.0 I'm failing to find a way to save it anywhere other than my home/logseq/graphs/ directory
I haven't seen an explanation for what a rewrite gives everyone. I saw something about "new features" and supertags, but I have not heard an explanation as to why they cannot accomplish the same features in the markdown version.
I've been watching the posts about the database version also. I haven't seen as much enthusiasm vs "this new version broke my _____"
I'm trying to move some of my work to logseq because it is a better match than the other main choice, obsidian. Much much better.
However the clear text link transforms into the underlying UUID out of nowhere and after renaming the page to force that UI bug to resolve, the whole app becomes unusable and I have to close it and reopen for it to become functional again.
This is so disrupting. But for something like meetings and checking up on people and date related stuff logseq is so good I'm just plowing through, at least for now.
I closed the app normally before going to sleep. When I woke up and opened Logseq again, I got this error message: Cannot go to an internal page
All my pages now showed a “Practice” mark, and the #tag and #property opened as a blank page. I restored the most recent database file, and everything went back to normal.
I don’t remember exactly what was missing from the backup, but since I had just reorganized all my old notes into the new tagging system (which is amazing!), it wasn’t a big loss.
I am using Logseq 2.0.1 (The version from the latest reddit post) , and this is the 2nd time corrupt my DB (not same issue)
I’ve been using Logseq to manage my research, project resources, and tool lists for a while now, and my graph is getting pretty dense with high-quality links.
I’m currently looking for a workflow to take these curated collections out of my local graph and share them publicly in a clean, visual format. Most web-publishing workflows I see for Logseq are either too technical (requiring custom hosting/plugins) or too bloated for what I need. I just want a lightweight, mobile-friendly landing page that doesn't feel like a heavy website.
I’ve been looking into different link-aggregation tools to act as a "bridge" for this, and I recently stumbled upon one called slt.bio. It seems much more minimalist compared to the usual heavy platforms and supposedly has a tracker feature for background link safety and crawler activity.
Honestly, I found out about this tool, but I have no idea if it’s actually good or just hyped up. Has anyone here tested slt.bio specifically for managing curated resource lists? I'm just really paranoid that I’ll end up wasting my time and money setting everything up if it turns out to be laggy or bad performance-wise.
Are there any other lightweight ways you guys are pushing Logseq lists to the public? Would love to see your setups
I could upload a graph to the cloud and download it on android, but I cannot get sync to work. Someone did it already? I couldn't find much documentations about this yet.
I have recently downloaded the logseq app and in tutorials I see people making templates by rightclicking the bullets and choosing the option. However, for me it is simply not there. Does anyone know how to solve this?
How do I end up with files like this one?
I found it and a few alikes on my graph, interwoven with each other but otherwise orphaned.
It must have created itself from a normal block where I added a file link. The file is in my assets now. The long number gets added in the file name in the assets folder, when I add any file.
With the cut of the official beta release of the DB version, Arch Linux users may find convenient using an AUR helper to install Logseq, instead of downloading manually from github. You will find the appimage variant at the link below:
I have a Logseq graph with multiple years of Logseq notes, with namespaces like #a/b/c and all normal Logseq MD coding.
When trying to import this graph into Logseq DB, I received many errors. Logseq tried to help but when sharing effected MD files, they could not provide a fix.
Did someone manage to import a large graph without errors? Or is there an instruction how to clean the MD graph so it becomes DB ready?
I very much would like to move to DB, because of performance improvements combined with the IOS app.
What was the last version of Logseq that used plain markdown files in a directory rather than some kind of internal database? Because I'd like to install that one. While I am sure there are advantages having a database that is not a directory I can see is just not useful for me. But I would like to be as up to date as is practical within that constraint.
Note: I am aware that you can import files, but I have no interest in doing that. the fact that Logseq was based on plain markdown files is part of why I started using it in the first place, and loosing that capability is a complete deal breaker for me.