Concerns on DB Version and Future State from a 3+ Year User

As someone who values the simplicity and organic flow of traditional outliners, I’ve found Logseq’s approach to be increasingly counterintuitive to the core strengths of an outliner over the years. While Logseq is undoubtedly powerful, especially for power users, it introduces a degree of rigidity and complexity that feels at odds with what outliners should provide—simplicity and the ability to organically structure information.

I’ve been using Logseq for over three years when Logseq was still in early alpha, and since that time, I’ve been an avid user. However, when I raised concerns about the decentralized structure in the DB Alpha feedback group, I was told by some community members to simply look elsewhere for other tools. This was surprising given my long-term investment in Logseq. It seems like the community focus has shifted more towards catering to advanced users, which doesn’t leave much room for those of us who want a simpler, more outliner-centric experience. With that said, I have been migrating my data for several months now, but with 3+ years of data it will take some time. I still think this is warranted to raise these concerns as I am sure there are other users who are feeling this pain and I do believe this would open the door to more users who would love to use Logseq.

Decentralized Page References Fragment Structure

Logseq’s reliance on Page References allows for a decentralized structure, but this creates its own set of challenges. Since Page References can be scattered across the graph, it becomes difficult to form a coherent, centralized structure. In a traditional outliner, everything naturally fits into a clear hierarchy, where relationships between ideas and concepts are immediately visible and easy to follow.

With Logseq, this decentralized model leads to fragmentation. There’s no single, unified place to see how all your references fit together, making it hard to navigate and understand the larger structure of your knowledge base. This is a sharp contrast to other tools like RemNote/Tana or Obsidian, where there is either a built-in hierarchy or a filesystem to fall back on for clear organization. Without a clear way to manage this fragmentation, it can feel like you’re constantly chasing scattered references instead of building a unified system.

Properties Introduce a Rigid Structure

Logseq’s properties are great for adding metadata to blocks, but they bring with them a rigid structure that can weigh down the simplicity of outlining. Outliners are supposed to let users evolve their thoughts organically, with structure naturally emerging through nested relationships. Properties, on the other hand, lock users into predefined fields like tags, statuses, or dates, which require constant management.

Instead of letting the structure emerge as you build, properties force you to think about how to categorize everything upfront. This rigidity adds friction to what should be an effortless process. You can’t just outline your thoughts—you now need to think about how to structure the data through metadata fields, and that’s not the natural flow most users expect from an outliner.

The Focus on Power Users

One of the things I’ve noticed is that Logseq is increasingly catering to power users who rely on advanced features like properties. While these features are undeniably useful in certain contexts, they introduce a rigid system that often demands upfront planning and a more structured approach to organizing information.

This shift is especially evident in the DB version, which places even more emphasis on the use of properties compared to the file graph version. For users who prefer a more organic and fluid outlining experience, this growing focus on properties and structured systems can feel restrictive. After three years of using Logseq, I’ve found it increasingly difficult to maintain the simplicity and flexibility that originally drew me to the tool.

It seems like the development direction is moving toward supporting advanced workflows, leaving users who value Logseq for its outliner capabilities feeling somewhat alienated. The outliner simplicity—where ideas could naturally evolve and structure themselves—now feels overshadowed by the need to manage and plan around structured properties and metadata.

Visual and Conceptual Rigidness

Logseq’s graph-based approach introduces visual and conceptual rigidness. In other tools, like RemNote or Obsidian, there is a more obvious visual hierarchy—a centralized space where users can easily organize their ideas. In contrast, Logseq’s graph model makes it harder to see how everything fits together at a glance. You can link blocks and pages, but without a centralized structure, it can feel disjointed.

In a traditional outliner, your visual hierarchy is clear: you nest items, move them around, and everything stays organized visually. In Logseq, you have to jump between references, pages, and queries to pull everything together, which makes it harder to see how your ideas fit into a larger whole. This rigid approach is especially problematic for users who are accustomed to seeing their thoughts and ideas clearly organized in one place, without needing to rely on graph views or complex queries.

I feel the exact opposite.

I have struggled to develop my ideas in Obsidian because information about any topic (say pineapple) is scattered in various documents, and it’s impossible to see everything I have written about pineapples in a single page.

I can make a folder named “pineapple” and throw all files that mentions pineapple into it. In some software this process can even be automated. But it’s still a folder of many pages, including a lot of information irrelevant to pineapple. Moreover, what if I want something about both pineapple and grapefruit? Do I need even more folders?

Logseq, with its page references, offers an effective solution for this.

For sure, not everyone needs to see all notes that mentions pineapple. But for those who do (me included), Logseq is a great weapon against mental anarchy. Are we “power users”? It depends on your definition.


If you want a single page about pineapple and write and arrange everything – in your preferred order – about pineapple on this page, then there indeed are better alternatives than Logseq. On macOS there are the long-established OmniOutliner and the radical, simplicity-obsessed Bike, both catering to the ideal of a conventional folder-and-document “very simple outliner”. (FYI both are one-time purchases, are macOS-native, and stores your data locally.)

I don’t like how the Logseq team conducts public relations. Their reluctance to providing technical documentation for non-programmers is particularly regrettable. That being said, they did have a point suggesting that there are better options for you.


About structure, IMHO your points are well-written and valid. But is structure a good thing to have? For me it is – structures in my notes reflect the structures of my thought.

Moreover, the structures are not as rigid as you might think. My property definitions change over time, reflecting the dynamics of my thought. In essence, my properties are “search indexes” which serve to augment queries and references. I make properties only when I think they would help with future retrieval of information. By no means do I see properties as self-inflicted limits to my notes.

Finally, I don’t share the conviction that all outliners should be simple. Among other things, the very notion of a database (Logseq is a graph database) embodies the opposite of simplicity.

There is not such a built-in hierarchy in Tana. If you want that hierarchy, you must built it (places like Home or Library enable to do that, but it is not its core). In fact, there is some sort of simplified object-oriented programming approach. Their motto “everything is a node” (block in Logseq) and the lack of “page” item aims for a decentralized way of building your system. That’s a scenario more similar to what Logseq might look like once the DB version is launched.

What I agree with you is about the “high friction” over time while creating that structure on top of your blocks (information atoms). I wrote an article, as an outcome of a 𝕏.com conversation I had with @TfTHacker where I share my thought about this matter :point_right:t2: Addressing Friction in Modern Productivity Tools: A Critical Perspective | by David Delgado Vendrell | Sep, 2024 | Medium

Personally, my work in Logseq consistently meets your criteria of 90% of typing time in the raw content and 10% enriching it with metadata. I add few double brackets on the fly, instead relying on a review session every night to add page and block references to what I wrote that day. The review session usually takes 10-30 minutes and feels quite enjoyable.

The only custom properties I frequently use are: review, compare, similar, aside from year for historical events. I understand that there will be excessive friction if you have to maintain more properties than you need.

I am referring to the decentralized approach Losgeq uses for Page References vs Tana’s approach to a structured approach with Node References stored in the library. With Tana, when you create a node reference, that node reference is created and stored in the Library. You then have the choice to go into the library and place it into a structured outline thus giving you a hierarchy. Then future references are all pointed back to that instance in the library based upon whatever hierarchy structure you place it under.

With logseq however these page references can exist all over your graph, making it impossible to provide a centralized and coherent outline. I could have a single page reference for “Transport Layer” that could exist across 20 different pages due to this decentralized approach, which leads to fragmentation.

3 Likes

What you are referring to is the reference panel. I have no issues with the reference panel and it was the one thing that I couldn’t do without since other tools do not offer anything close to what Logseq has done.

For me it is not, that’s where tools have to realize that not every person has the same approach to how they achieve a task. Just as you probably do not learn new things the same way I do, you do not structure your notes the same way as I do. I heavily rely on an outliner structure to give me a visual clue and be able to get a grasp of the entirety of a given topic. None of that means the way you do it is wrong, nor is my approach wrong. If a tool is aiming to achieve or capture a certain % of the user base then they should allow this flexibility in their tool, of course this is all based on what direction they want to take their tool. Logseq back in the alpha days was heavily based on outlines, it was inspired by org-mode that’s a outliner note, but that’s changed overtime. Intentionally? I have no clue, but I have not seen anybody bring these issues up, and with me being a user for as long as I have been to see this shift I think it warrants bringing the concerns up.

1 Like

I fully appreciate the diversity of plausible approaches. That being said, that an approach makes sense (or “is not wrong”, in your term) does not automatically qualify the approach as right. A right approach should both (1) suit the user’s specific needs, and (2) conform to the peculiarities of the specific tool.

You need a “centralized structure”. Logseq does not offer a “first-class” way to construct it. You’re deeply troubled by this peculiarity of Logseq. This suggests something is wrong with your approach.

You can retort that it’s Logseq’s approach that has been wrong. This counterpoint is not without its merit. Nevertheless, no matter whether Logseq’s approach is wrong or not, your approach is definitively not quite right — you are expressly troubled by it!


I don’t mean to discredit your approach. The point is, we adapt to our tools more than our tools adapt to us. Have you tried e.g. using a pineapple/index page, or #index tags to signify “centralized structure”? (Disclosure: I have tried exactly that and decided I don’t really need it.)

The way I’m using Logseq now is quite different from what I envisioned more than two years ago. I’m happy that I did not stick to my original system. YMMV.

1 Like

I think there’s a misunderstanding about the fundamentals of what makes an outliner effective—especially when comparing Logseq to more traditional tools like Dynalist, Workflowy, Org-Mode, Tana, or Remnote. The key issue here isn’t that I’m struggling to adapt to Logseq’s design; it’s that Logseq itself departs from the core strengths that make outlining tools so valuable in the first place.

Outliners, at their core, are meant to provide a clear, centralized structure where ideas can be easily organized, navigated, and built upon. Logseq, however, has chosen a more fragmented approach, which can create friction for users who expect a more unified experience. You’ve suggested using an index page or #index tags to simulate that structure, but these are workarounds for something that traditional outliners provide naturally—a cohesive, first-class outlining experience.

The decentralized model that Logseq relies on, with its emphasis on page references and tags, lacks the built-in hierarchy that tools like Dynalist or Org-Mode offer. Instead of offering a clear, top-down view of your information, you end up jumping between scattered references, piecing things together as you go. For some users, this flexibility is a strength, but for those of us who prefer a structured, centralized system, it feels disjointed and counterintuitive.

The issue isn’t that I’m unwilling to adapt to Logseq’s methodology; it’s that Logseq doesn’t inherently offer the same core functionality that traditional outliners do. Suggesting that I simply adapt my workflow misses the point—Logseq isn’t designed to provide the kind of coherent outlining experience that’s standard in other tools. Instead, it fragments information across pages and blocks, forcing the user to manually stitch it back together.

While I understand your argument that tools evolve and users must sometimes adjust, it’s not unreasonable to expect a tool that calls itself an outliner (reference section “Introducing Logseq: a networked outliner”) to offer what traditional outliners do: simplicity, cohesion, and clarity. I’ve been using Logseq for years and understand its strengths, but it’s hard to ignore the fact that for users who prioritize a centralized structure, Logseq’s design creates friction that shouldn’t exist in an outliner.

At this point I will hold off on any further comments as I believe I have delivered all my major points regarding the comparison between Logseq and traditional outliners. I will leave the conversation open for the Logseq team to share their thoughts and perhaps clarify their vision for the tool’s development if they wish to do so. They did mention in the alpha group they wanted to hear all feedback regardless of context, and I hope that this contributes to their continued reflection on how Logseq aligns with the needs and expectations of its users.

2 Likes

MODERATION POST

This is a reminder to everyone:

  • We discuss topics, not persons.
  • Any questions on behaviors or policies should go to private messages.
  • All posts are subject to moderation, especially those failing the above.
    • Moderation is rare, so think twice if it happens to your post.
2 Likes

@Zyrohex I agree with a lot of your thoughts, and I also share a lot of your concerns with the current db version, especially how the “outliner simplicity” has been lost in translation. (for the context, I’m also a 3+ year user).

My hope for the db version was to retain the intuitive nature of vanilla logseq while adding (optionnal) advanced metadata and solving performance issues, but from my limited time with the current test db version :

  • the learning curve is way steeper and the workflow is less forgiving (what I really like in vanilla logseq is the simplicity of outlining, so anyone can just start to write, then on a later stage, do some tidy up and organization…basically, “write then plan” . Now it feels like it compels you to think ahead, plan before you write (not saying this is always bad, but it’s a very different use-case)
  • new “advanced” features replacing legacy features rather than complementing them. for instance tags and pages-refs are now different. “new tags” do not behave like inline tags. sounds simple but it requires more thoughts, adds mental burden : should I tag or link ? what category/class ? what would be the consequences ? what would be the benefits ? what is my taxonomy ? should I create a whole ontology before writing in fear of refactoring ?
  • now everything is a node, pages are a group of nodes. this could be nice (probably remnote’s greatest feature), but in logseq’s current implementation, it just add a lot of extra noise in search and autocompletion lists. Also nodes can exist outside of pages. As you said, it create fragmentation and noise - more mental burden. We need power filtering and sorting options.
  • the raw performance is better in most cases (better for long pages, better for lots of blocks, better for tables), but the UX is still very alpha so the usage improvements don’t feel as massive in my case (but again, I need to spend way more time to form a definitive opinion, plus UX will probably improve drastically soon enough).

I 100% agree with @stdword when he said in the discord channel : “Logseq DB — is another application, not next version.”

I was hoping to build on my existing structured notes and expanding my workflows with the db features, but in the current state, it feels like I need to re-built my graph from the ground up, almost like transitioning to a new app (and this will trigger existential questions for some users).
I was able to import my notes to the db version, but the import/convert script was not smart enough to turn my graph into a useful database unsupervised (tags being lost, properties/values not being smartly converted), lack of granular options on import, some formatting issues, lost refs, nested tags issues, etc)…
But it’s not a lost cause, I’m sure many things can (and will) be improved
in the coming months, Ijust hope logseq doesn’t lose its essence in the process of getting shiny new features.

3 Likes

I like the decentralised system because it is more flexible, allowing people to build their own structures.

A centralised system can be implemented within a decentralised one. The opposite is impossible.

2 Likes

I believe that Logseq is designed to afford a level of creativity that I personally value, as an interdisciplinary writer. If you need a tool that divides knowledge into silos, then Logseq may not be the tool you want it to be.

Thanks for sharing Bob! I think both can co-exist in the same system so that those of you who love the de-centralized system can still retain that de-centralized approach while those who look for a centralized approach can achieve one. Here’s how I envision it:

  • A centralized list of all pages/objects can exist within a decentralized system (similar to Tana’s “Library” or “All Pages” section).
  • This list would remain a flat, unmodified view of all pages, providing a centralized point of reference.
  • Users can still build their own structure and connections organically by linking and referencing pages within the graph.
  • The flexibility of the decentralized approach remains intact as users aren’t forced into a hierarchy, even though a central repository exists.
  • Users can still reference any page, and the decentralized structure allows flexibility in how they organize and connect their information.

I am a 3+ years user too and I am worried about the implementation of the DB version.

I have used only Logseq MD in my job and it is the best application to take notes quickly, taking advantage mainly of Journal pages, indentation and Linked References. I use properties to build a very simple relational database on the fly.

Recently I have started to experiment with Logseq DB and basically I use Logseq MD like most people would use Word and Logseq DB like Excel. The Word/Excel combo is something I have always hated because it introduces fragmentation and I am experiencing the same with Logseq MD & DB.

Also I am very tempted to go back to plain text files, folders and symlinks, this time with scripts to mimic the query features I use the most in Logseq. Indeed as a developer I prefer “frameworks” to Apps™ and more importantly progressive enhancement and graceful degradation. Sadly there is not enough of these between plain-text/Logseq-MD/Logseq-DB.

4 Likes

As a new user and someone with only layman tech chops, I can attest to experiencing this sensation already in my brief time with the platform. My auto-response to that, which I confess I sometimes can muster only with effort to overcome the sensation, is give it time. You’re only getting started.

I like this idea specifically, and maybe even more, the philosophy behind it. It is a way of both recognizing the inevitability of friction inherent in creating structure, and of sequestering that friction into a planned time period.

To carry this thought back to @Zyrohex 's original point(s), I never expected that any tool could create a frictionless experience. Nor was I wanting a frictionless experience. Floating gravity-free in outer space may be cool and it makes some processes possible that are impossible on Earth, but gravity has tremendous benefits, like making it possible to manage rainfall drainage around a home. Without gravity, I wonder what would replace the rooftop of a house. Without having to work against the gravity of structure, accumulated information becomes undifferentiated noise.

So it’s not a question of removing friction; it’s a question of the kind of friction I prefer to deal with: After the fact, as with a directory/folder system? Or before the fact, as with a tagging/linking system? The journey from the former to the latter, as I am experimenting with now here in Logseq, is unsettling, at least so far. There are moments of panic, e.g. “constantly chasing scattered references,” but there are also moments of new clarity and power when the forethought of taggling/linking comes together during retrieval. Is the latter preferable to the former? For me, the jury is still out, but I warm up to Logseq a little more each day.

What I really do find attractive in Logseq is the ability to just dump new input into a journal, and not have to immediately decide what to do with it. I can come back to the raw input at a moment when I’ve got clarity on how to tag it up, trusting that, having done so, it won’t dissappear into a Fangorn of folders where I’ll never be able to find it again.

1 Like

I’m not going to say there is any comprehensive philosophy in the way I work. The idea is essentially an adaption of the wisdom that if you write a lot, then it’s imperative that you review your work regularly. Many novelists, for example, keep a habit of reading out aloud to family what they have written in the day.

It occurred to me one day that the work of adding double brackets is identical to the kind of work called “reviewing”.

1 Like