Logseq talks about the DB version

TL;DR

Markdown support is not being deprecated; the roadmap targets two-way sync so markdown remains readable while the database becomes the main change-recording layer.

Briefing Cornell Notes

Briefing

Jensen’s announcement on Logseq’s database version reframes the roadmap around one central tradeoff: keep a readable, text-based workflow while shifting the “source of truth” toward a persistent database that can support collaboration, richer structure, and safer syncing. The long-term goal is seamless two-way sync between the database and markdown files—so users can adopt new database-backed features without immediately abandoning the plain-text approach that made Logseq popular.

A key clarification addresses a common fear: markdown support is not being dropped. Instead, markdown and database graphs will run in parallel at first, with the database becoming the main place where changes are recorded. Over time, the system will rely on two-way sync, which may feel slower than direct file edits but is expected to improve reliability and consistency. The rationale is straightforward: markdown files are great for readability and portability, but they’re a poor foundation for frequent, multi-user updates and for maintaining stable references across renames and reorganizations.

The database version is positioned as a solution to several pain points that show up when Logseq scales beyond solo use. Collaboration is the headline problem: building real-time co-editing on top of markdown is extremely challenging because edits often require rewriting entire files, and concurrent changes can become brittle. The transcript highlights how databases handle identity more robustly—using persistent IDs rather than names—so renaming a page doesn’t require rewriting every reference throughout the graph. It also points to structured data limitations in markdown: adding IDs, timestamps, and relational metadata would clutter readability, defeating markdown’s purpose.

Beyond collaboration, the database version aims to improve performance and data integrity on large graphs. Concerns raised include slow indexing, unreliable undo/redo when syncing is involved, and data loss during multi-device sync conflicts. The database approach is described as more merge-friendly than file overwrites, since changes can be added to the database rather than discarded. Still, the transcript repeatedly stresses that stability—especially reliable undo/redo and trustworthy syncing—must come first, because users will tolerate missing features far more than they will tolerate lost data.

The roadmap also ties the database to broader platform goals: better web support, cross-platform access across Electron, mobile, and web, and advanced querying. Real-time collaboration is treated as a major engineering lift, especially with offline support. The transcript notes that offline-first real-time collaboration requires complex conflict resolution and replication logic, and that Logseq’s team explored approaches like CRDTs but ultimately found existing solutions didn’t meet its requirements.

Finally, the plan is staged: pre-alpha testing in 2–3 months, then expanding to larger groups, followed by public beta with backups strongly encouraged. Local features are expected to remain free, while server-dependent capabilities—like real-time collaboration and public sharing—likely require paid services. The overall message is that the database version is a foundational shift aimed at making Logseq’s data safer, its structure more powerful, and its collaboration more practical, without abandoning the readable text workflow that users rely on.

Cornell Notes

Logseq’s database version is designed to become the system of record while keeping markdown as a readable, file-based layer. Markdown won’t be deprecated; instead, the roadmap targets two-way sync so users can adopt database-backed features gradually. The database addresses core limitations of markdown for collaboration and structured data—especially persistent IDs (so renames don’t break references), better handling of concurrent edits, and more reliable syncing across devices. Real-time collaboration with offline support is treated as a difficult, separate engineering challenge, so testing is staged through pre-alpha and beta phases. The shift matters because it aims to improve data safety, undo/redo reliability, performance on large graphs, and eventually web-accessible collaboration—without forcing users to abandon plain-text workflows.

Why does a database help more than markdown when multiple people (or devices) edit the same graph?

Markdown is file-based, so concurrent edits can force large rewrites and make merges brittle. The transcript highlights that creating or updating blocks in markdown can require rewriting entire markdown files, which becomes problematic when several clients change content at the same time. A database can store changes as structured updates, keep stable references via persistent IDs, and avoid name-based brittleness—renaming a page updates references automatically because other records point to an ID rather than a mutable name.

What does “two-way sync” between the database and markdown mean in practice?

The plan is to run both representations in parallel at first: users can create new graphs backed by the database to access new features, while others can keep working primarily in markdown. Over time, the database becomes the main place where changes are recorded, and markdown files are kept in sync through a slower but more consistent two-way mechanism. The goal is to preserve the readable text workflow while still benefiting from database capabilities.

How do persistent IDs reduce breakage compared with name-based references?

In a markdown-first approach, renaming a page can require scanning the entire graph and updating every textual reference (e.g., bracketed links) to the old name. That process is error-prone and makes the system brittle. With a database, references use IDs that don’t change; when rendering, the app looks up the current title for display. This makes renames safer and reduces the risk of broken links.

What are the biggest engineering risks for real-time collaboration with offline support?

The transcript frames offline real-time collaboration as extremely complex because it requires conflict resolution when multiple clients edit while disconnected, then reconcile later. It compares the online experience (like Google Docs) where all changes flow through a shared backend, with offline scenarios where there’s no single source of truth. Approaches such as CRDTs were explored, but existing solutions were said to not meet Logseq’s needs, leading to a more custom build.

Why is stability—especially reliable undo/redo and no data loss—treated as the priority?

The transcript argues that users will tolerate missing or delayed features more than they will tolerate lost data or broken undo/redo. If the system is unstable, people will switch tools. The database roadmap is therefore tied to improving data integrity and sync behavior first, then layering on performance, collaboration, and publishing improvements once the core is trustworthy.

What does the staged testing plan look like, and why does it matter for users?

Testing is described as moving from pre-alpha (a small group, not production data) to larger groups, then public beta. The transcript emphasizes that beta can break and that users should keep backups. For collaboration testing—especially server-backed features—only more technical groups are expected to participate early, since issues may require frequent reinstallations or debugging.

Review Questions

What specific markdown limitations make collaboration and structured data harder than with a database, according to the transcript?
How do persistent IDs change the behavior of renaming pages compared with text-based references?
What makes offline-first real-time collaboration technically difficult, and what role does conflict resolution play?

Key Points

1
Markdown support is not being deprecated; the roadmap targets two-way sync so markdown remains readable while the database becomes the main change-recording layer.
2
Early adoption is expected to work by creating database-backed graphs for new features while allowing markdown-heavy workflows to continue temporarily.
3
Persistent IDs are central to reducing brittleness—renames and references should remain stable because links point to IDs rather than mutable names.
4
The database version is meant to improve reliability for multi-device syncing, undo/redo, and large-graph performance by avoiding file-rewrite merge problems.
5
Real-time collaboration with offline support is treated as a major, separate engineering challenge requiring complex replication and conflict resolution.
6
Testing is staged (pre-alpha → expanded testing → public beta), and users are urged to use backups because beta software may break.
7
Local features are expected to stay free, while server-dependent capabilities like real-time collaboration and public sharing likely require paid services.

Highlights

The database version aims to make the database the system of record while keeping markdown as a synced, readable layer—so users don’t have to abandon text files to gain new capabilities.

Renaming becomes safer with persistent IDs: references don’t require graph-wide textual rewrites because they resolve by ID at render time.

Offline-first real-time collaboration is described as exceptionally hard due to conflict resolution when clients edit without a shared backend connection.

The roadmap prioritizes data safety and reliable undo/redo before expanding collaboration, performance, and publishing features.

Local vs server-dependent features are separated in the business model: local remains free; collaboration and public sharing likely cost money due to infrastructure needs.

Topics

Logseq Database Version
Two-Way Sync
Persistent IDs
Offline Collaboration
Pre-Alpha Testing

Mentioned

Jensen
CRDT