Logseq 2.0 Beta (DB version) is here

Logseq 2.0 beta is officially here, and it marks the most significant architectural overhaul in the note-taking tool's history. Released under the tag 2.0.1, the Logseq 2.0 beta (DB version) replaces the app's foundational file-based storage model with a SQLite database engine — a change that reshapes how the tool stores, syncs, and scales knowledge graphs for the users who depend on it daily. If you have been following Logseq's development roadmap, the arrival of the Logseq 2.0 beta version is the moment the team has been building toward for years.

What Exactly Is the Logseq 2.0 DB Version?

For context: Logseq built its reputation on a deceptively simple idea. Every note, every journal entry, every block of thought was stored as a plain Markdown or Org-mode file on disk. Your knowledge graph was, at its core, just a folder of text files — readable by any editor, portable across platforms, and immune to proprietary lock-in. That was its greatest strength and, as the application grew more complex, its most significant engineering constraint.

The Logseq 2.0 beta replaces that plain-text substrate with SQLite, the battle-tested embedded relational database engine that powers everything from mobile applications to web browsers to embedded systems. Unlike client-server databases, SQLite requires no separate server process and stores its entire dataset in a single binary file — a design that turns out to be a natural fit for local-first software. Instead of parsing Markdown files on every launch and maintaining a large in-memory graph derived from them, Logseq 2.0 writes to and reads from a structured, indexed database. The development team refers to graphs created under this new system as "DB graphs", distinguishing them clearly from the legacy file-based graphs most existing users have accumulated.

The team has been candid about the beta's maturity level: the release messaging describes it as an early beta with rough edges, and the team's guidance explicitly warns that data loss remains a real risk. Automated backups and regular manual SQLite database backups are strongly recommended before anyone migrates a production graph into this version.

Why Logseq Is Splitting Into Two Versions

One of the more consequential aspects accompanying the Logseq 2.0 beta is that Logseq is effectively splitting into two distinct product lines. This is not a typical major-version cutover where the old version is deprecated and users are shepherded onto the new one. Instead, both are set to coexist on parallel tracks:

• The file-based version (the Markdown/Org-mode Logseq most users know today) continues to be maintained, receiving bug fixes and stability improvements. The 0.10.x branch remains active — releases have continued shipping with dependency updates and targeted fixes such as Electron bumps and embed corrections.
• The DB version (Logseq 2.0 and beyond) is the forward-looking branch built on SQLite, targeting users who want real-time collaboration, advanced mobile sync, and structured database querying at scale. This branch is set to receive the bulk of new feature development going forward.

This dual-track strategy is unusual in consumer software but makes clear strategic sense in this context. Logseq's file-based version has a large, vocal user base that has built elaborate workflows around the guarantee that their data lives in plaintext files they fully control. Forcing a hard migration would be a community crisis. By keeping both alive, the team can push the new architecture forward without abandoning the users who made the product what it is — a pragmatic, if operationally demanding, compromise.

Editorial note: Why it matters. The split signals that Logseq's ambitions have outgrown what a plain-text file system can realistically support. Real-time collaboration, structured property queries, and cross-device sync at scale all demand database semantics — and SQLite delivers them without sacrificing the local-first philosophy that defines Logseq's identity. The dual-track model is the team's way of saying: the future is DB graphs, but we will not force you there before the tooling is ready.

Under the Hood: SQLite, RTC, and the New Mobile App

SQLite as the Storage Layer

SQLite is an embedded, serverless, zero-configuration relational database library. Unlike client-server databases such as PostgreSQL or MySQL, SQLite stores an entire database in a single .db file on disk — which means Logseq's core promise of local-first, offline-capable storage is not broken by the transition. Your data still lives on your machine; it is simply structured in a binary database file rather than a folder of human-readable Markdown documents.

The practical performance implications are substantial. A file-based graph with tens of thousands of blocks requires Logseq to parse every file on startup, construct an in-memory index, and keep that index synchronized continuously as the user edits. With SQLite, reads and writes become indexed database operations with well-defined transactional semantics. Queries that currently require full-graph traversal — finding every block that carries a specific property value, aggregating task completion statuses across dozens of pages, filtering entries by date range — become SQL queries that can execute far faster even on very large graphs. The startup-time improvement alone is expected to be a meaningful quality-of-life gain for power users with mature, heavily linked graphs, though the exact figures will depend on graph size and hardware.

Real-Time Collaboration (RTC)

The DB version ships with a new sync architecture built around RTC (Real-Time Collaboration). Unlike the existing Logseq Sync service, which is essentially a file-level sync mechanism that periodically pushes Markdown changes to the cloud and resolves conflicts file-by-file, RTC is designed for concurrent multi-user editing with block-level conflict resolution — the kind of live, coherent collaboration that tools like Notion and Confluence provide. It is important to be precise about the current state: as of the 2.0.1 beta, RTC is described as being at an early, alpha-grade stage, making it even less mature than the broader DB version beta in which it is bundled. Users should not rely on RTC for any critical shared workflows until it advances to at least a beta stability designation.

New Mobile App

The DB version also introduces a new mobile application built natively around the SQLite storage model. The iOS version is available now; Android support is listed as coming soon. The existing mobile apps were built to serve the file-based version and carried the inherent complexity of syncing Markdown file trees across devices — a process that was reliable but slow and prone to conflicts on frequent saves. The DB-native mobile app is designed from the ground up around the SQLite model, which should translate to faster load times, more reliable real-time sync, and an interface capable of exposing structured database features such as property-based views and filtered queries — capabilities that are difficult or impossible to build cleanly on top of plain-text files.

File-Based vs. DB Version: A Direct Comparison

The table below summarizes the key differences between Logseq's two product lines as of the 2.0.1 beta release.

Feature	File-Based Version (0.10.x)	DB Version (2.0 Beta)
Storage format	Markdown / Org-mode plaintext files	SQLite .db binary file
Human-readable files	Yes — any text editor can open them	No — binary database format requires export
Graph type label	File graphs	DB graphs
Sync mechanism	Logseq Sync (file-level, periodic)	RTC — Real-Time Collaboration (alpha)
Real-time multi-user editing	No	Planned — currently alpha-grade
Mobile app	Existing Logseq mobile app	New DB-native app (iOS now, Android soon)
Query performance on large graphs	Slower — file-parsing overhead on startup and queries	Faster — indexed SQL operations
Stability	Stable — production-ready	Early beta — data loss is possible
Development focus	Bug fixes and stability (no major new features planned)	Active development — new features and architecture improvements
Data portability	Very high — plain files, git-friendly, universally readable	Lower — depends on maturity of export tooling
Plugin ecosystem compatibility	Full — existing plugins are built for this model	Partial — significant plugin rewrites likely required

What This Means for Existing Logseq Users

The honest answer for the majority of users is: not much needs to change right now. The file-based version is not being retired, and the 2.0 beta is explicitly not ready for production workflows. The team's published guidance is clear — back up all your data, experiment with the beta using a dedicated test graph, and report issues through the GitHub issue tracker rather than filing support requests for expected rough edges.

The longer-term implications, however, deserve serious consideration. If the DB version becomes the primary focus of feature development — which the two-track structure strongly implies — the file-based version will gradually fall behind on capabilities. Users who care about structured database views, advanced property-based querying, real-time collaboration, and a capable mobile experience will eventually feel the pull toward Logseq 2.0. At that point, the migration question becomes unavoidable rather than optional.

The migration path itself is not yet fully documented in the 2.0.1 release. The team points to a live public roadmap for details, but the critical specifics — exactly how a user converts years' worth of Markdown notes into a DB graph, and whether that process is fully lossless for block references, linked pages, embedded queries, and property values — remain among the most closely watched open questions in the community. These are not edge cases; they are fundamental to whether the existing user base will trust the migration enough to commit to it.

The fact that the new mobile app targets iOS before Android also hints at where the team perceives its next growth audience, which has implications for prioritization across the roadmap more broadly.

The privacy implications of this shift are also worth examining carefully. The file-based model made it trivially easy to audit exactly what data Logseq touched — your files were your files, inspectable with any text editor. With a SQLite binary as the storage format and RTC sync layered on top, the surface area for data-handling questions expands meaningfully. This is a consideration any privacy-conscious user should evaluate, particularly given the broader industry pattern of tools handling personal data in ways that are not always immediately transparent — a dynamic explored in depth in discussions of how major platforms manage and leverage user health data.

The Broader Context: Local-First Apps and the Database Inflection Point

Logseq's transition from flat files to SQLite is part of a larger and genuinely important pattern in the local-first software movement. Tools in this space — Obsidian, Notion, Roam Research, Tana — have each made different bets on the storage-versus-flexibility spectrum, and those bets have shaped their trajectories in fundamental ways. Obsidian doubled down on plain Markdown and built a thriving, independent plugin ecosystem on top of that commitment. Notion went fully database-native and cloud-mandatory, trading portability for structural power. Roam pioneered the block-reference model but faced persistent performance criticism at scale. Tana explored a proprietary node graph with structured supertags. Logseq is now attempting something architecturally more ambitious than any of them: a database-native foundation that aims to preserve local-first semantics.

The SQLite choice is significant precisely because it does not require a server or an internet connection. Unlike Notion's cloud-mandatory model, a Logseq 2.0 DB graph can live entirely on your device, be backed up with a simple file copy, and function fully offline without any degraded mode. The RTC layer sits on top of that local foundation, adding collaboration as an optional capability rather than a structural prerequisite — which aligns with the local-first architecture pattern that researchers such as Martin Kleppmann and colleagues have advocated as the correct model for personal data tools in their widely cited "local-first software" essay. Whether the RTC implementation holds up under real-world concurrent-editing conditions is precisely what this beta period is designed to stress-test.

For developers and power users who track these architectural decisions, the move also carries significant implications for the plugin ecosystem. Logseq's existing plugins interact with a Markdown-based graph model: they read and write files, parse block structures from text, and hook into the in-memory graph that Logseq builds at startup. DB graphs expose fundamentally different data structures and query interfaces — SQLite tables, property schemas, and indexed block relationships rather than raw text. Plugin authors will likely need to substantially rewrite or fully rebuild their extensions to support Logseq 2.0, and the scope of that effort will depend heavily on the quality and completeness of the plugin API documentation the team publishes. As of the 2.0.1 release, comprehensive plugin migration documentation has not yet been broadly available, which means the plugin ecosystem will lag the core application during the early beta period.

The open-source and knowledge-management community has long understood that the architecture underneath your data matters enormously over the long run — as demonstrated repeatedly by how open data principles prove their resilience when proprietary systems fail or are discontinued. Logseq's decision to build on SQLite — itself a public-domain, open-format database whose authors have publicly committed to supporting it through the year 2050 — keeps the data substrate technically open even as the format shifts away from human-readable plaintext. A SQLite file can be opened, read, and exported by dozens of independent tools; it is not an opaque proprietary format, even if it requires different tooling than a Markdown file does.

Key Takeaways

• Logseq 2.0 beta (DB version) shipped as release tag 2.0.1 — the most significant architectural change in the application's history.
• The new version replaces Markdown/Org-mode file storage with SQLite, enabling faster indexed queries, structured database semantics, and a foundation for real-time collaboration.
• Logseq is effectively splitting into two distinct versions: the stable file-based 0.10.x branch focused on bug fixes, and the forward-looking DB version receiving active new feature development.
• Real-Time Collaboration (RTC) ships with the beta but is alpha-grade — it is not suitable for production shared workflows at this stage.
• A new DB-native mobile app is available now for iOS, with Android support listed as coming soon.
• Data loss is possible in the beta; the team strongly recommends backing up all existing data before testing and using a dedicated test graph rather than a primary production graph.
• Migration tooling and plugin compatibility documentation for the DB version are still works in progress as of the 2.0.1 release — existing plugin authors should expect significant update work ahead.
• The local-first philosophy is preserved: SQLite stores all data on-device in a single portable file, with no mandatory cloud dependency.
• SQLite is public-domain and open-format, meaning the data substrate remains technically open and accessible to third-party tooling even without human-readable plaintext files.

What Comes Next

The immediate priorities for the Logseq team following the 2.0.1 release will be hardening the beta against data-loss scenarios, improving startup reliability across operating systems, and advancing the RTC sync layer from alpha to a beta-grade stability level suitable for real shared workflows. Beyond those stabilization goals, migration tooling will be the single most consequential deliverable for winning over the existing user base: a clear, reliable, and verifiably lossless path for converting file-based graphs — including all block references, bidirectional page links, embedded queries, and custom property values — into DB graphs is the prerequisite for broad adoption. Without it, even enthusiastic users will hesitate to commit their primary knowledge base to the new system.

The live public roadmap referenced by the team is expected to detail these milestones, giving the community the visibility it needs to plan. Plugin authors will be watching closely for API documentation that tells them exactly what to rebuild and what is safe to port directly. Android users will be waiting on the DB-native mobile app that puts them on equal footing with iOS users.

What is already clear is that Logseq 2.0 is not a minor version bump. It is a full foundational re-platforming — the kind of architectural investment that takes years to pay off but that, if executed well, enables a decade of capabilities that simply could not exist on a plain-text file substrate. The beta period ahead will be the real test of whether the SQLite-first architecture delivers on that promise in ways that the community can feel in daily use.