Logseq's New Database Version, Relationships and PKM with ToolsonTech

A major theme running through the conversation is that long-term productivity gains come less from chasing new tools and more from committing deeply to one system—then designing it so it reduces cognitive load over years. That idea shows up in how both participants talk about relationships, journaling, and note-taking: the goal isn’t to capture everything, but to create “hooks” that let the mind quickly re-access what matters, whether that’s a past emotional state, a work topic, or a set of tasks.

On personal knowledge management, the discussion pushes back against overcomplicated “atomic” approaches. Instead, it distinguishes between two practical note types: (1) ongoing journal-style entries meant for quick reference over the next days or weeks (often meeting notes), and (2) topic pages that consolidate and clean up information into a single place for fast re-absorption. A recurring method is outline-first structure: large sections for main topics, a second level for specific queries or subtopics, and a third level for details that stay folded so the page remains scannable. The outline becomes a retrieval tool—helping users rediscover what they already wrote, spot gaps over time, and avoid the “searching for what you forgot” problem.

The conversation then pivots to Logseq’s upcoming database version, where the stakes are technical but also existential for users: stability, data safety, and the ability to keep notes accessible outside the app. The database rewrite is described as a shift from Logseq’s earlier markdown-first, file-based assumptions toward a core system where blocks are fetched by ID and relationships are resolved through the database. That change promises speed and a more consistent internal foundation, but it also forces rewrites of features that used to rely on markdown conventions—most notably tasks. Instead of parsing lines that start with “to-do,” the new approach uses hashtag-based task structures and properties, meaning users will have to adapt even if the day-to-day workflow (e.g., pressing Control+Enter to create tasks) still feels familiar.

Because the rewrite is large and risky, the team is portrayed as moving through staged releases: an alpha for trusted internal testing, then beta once the system is “99% stable,” with frequent backups as the safety net. The participants emphasize that open-source users still expect reliability—especially avoiding data loss—even if they don’t pay for support. They also argue that any sync strategy must preserve user control: ideally, Logseq should treat the database as the “golden source” while maintaining a robust two-way markdown sync so notes remain readable and portable.

Finally, the discussion broadens into how tools and systems should support human behavior rather than fight it—whether that’s journaling as a way to observe thoughts without turning them into an onslaught, or using AI summaries carefully so the sender verifies what matters. The database rewrite becomes one more example of the same principle: build foundations that make retrieval, communication, and long-term trust easier, not just features that look impressive in the moment.