The future of Logseq - Sneak peek at the DB Branch

Logseq’s “DB branch” is a major behind-the-scenes shift aimed at replacing the app’s current markdown-file backend with a real database-backed engine—fixing long-standing stability and multi-window editing problems while unlocking faster, more scalable performance. The branch is far ahead of the production “master” line (thousands of commits), and it’s already been partially merged back so the work is actively converging toward something end users could eventually run.

The core motivation is that Logseq stores data locally, primarily as markdown. That approach works for single-user editing, but it struggles when multiple editing contexts need to coordinate—such as opening a second window and making changes that the first window must reconcile. With markdown as the persistence layer, Logseq can’t easily understand that two windows are working on different “screens” or that their changes should be treated as compatible updates. The result is a brittle experience: warnings about disk changes, missing metadata, and a growing mismatch between what users expect from a structured knowledge tool and what a text-format backend can reliably support.

The DB branch targets the “engine” layer—the component between the user interface and the stored data. The transcript frames this as a rewrite that must preserve compatibility with years of user-created content and workflows. Like improving a house over time, the system has accumulated many “fixtures” (features, assumptions, data formats) that a new engine must still support. That’s why the change takes so long: it’s not just building a database, but migrating behavior, preserving exports/imports, and ensuring the new engine doesn’t break existing users.

A key promise is better performance and stability through database-style access patterns. Instead of loading the entire note graph into memory, the database backend could fetch only what’s needed, reducing memory pressure and speeding up large workspaces. The transcript also highlights export as a practical concern: the DB branch introduces an “SQL light” export, but early tests produced a key-value style output with EDN-encoded data—useful for round-tripping but disappointing for users who want human-readable exports. By contrast, standard markdown exports remain clean and portable, and the speaker argues that export quality will determine whether users can confidently adopt the new backend.

On the user-facing side, the DB branch also changes how Logseq models data. The interface introduces clearer separation between “graph/database” modes and adds property-driven block types that feel more like configurable templates. Tags can generate extra properties automatically (e.g., a “meeting” tag populates structured fields), and tasks become property-based rather than a separate concept. Property types include text, numbers with choices, dates, checkboxes, URLs, and pages—plus inheritance via classes—letting users build structured systems (like books with authors and GoodReads links) without scattering custom schemas across the graph.

Overall, the DB branch is portrayed as a foundational upgrade: a database-backed engine to stabilize multi-window editing and improve scalability, paired with a more structured, property-centric UX. Remaining gaps include polishing task formatting, clarifying how templates work, and expanding query and view options (boards, calendars) once the backend is ready for broader load testing and optimization.