# Logseq as a team knowledge base means choosing which Logseq you mean > Logseq split into two apps in April 2026. One keeps your pages as markdown files and has no multi-user mode. The other has teammates and a SQLite database. Source: https://baalda.com/blog/logseq-team-knowledge-base Site: Baalda, https://baalda.com Published: 2026-10-11 **Short answer.** Logseq split into two apps in April 2026. Logseq OG keeps every page as a markdown file but has no multi-user mode and is now maintained rather than developed. Logseq 2.0 adds real-time collaboration and stores the graph in db.sqlite instead of files. A team is choosing between owning the files and having more than one person in them. Every team that tries Logseq arrives at the same wall on the same day: the moment a second person needs to be in the graph. Until 2026 there was one honest answer to that, which was that Logseq did not do it and you should put the folder in Git. There are two Logseqs now, and the answer depends on which one you installed. That is a bigger difference than a version number suggests, because the two versions disagree about where your notes physically are. One keeps every page as a markdown file in a folder you can open. The other keeps the graph in a SQLite database and writes markdown out as a copy. Baalda is built on the other side of that trade, so this post is not neutral and says so up front: the `.md` file on disk stays the durable source of truth and a CRDT keeps every open copy of it in sync, which is a claim that only means anything if you know what Logseq gave up to get the same collaboration. ## Can a team use Logseq as a shared knowledge base? Yes, as of 2026, and not in the way the page currently ranking first tells you. That page is a Thoughtworks Technology Radar blip published on 26 April 2023, which placed Logseq in Assess and said it "can be adapted for team use with Git-based storage". Thoughtworks has since retired the blip. The page now carries a banner reading "NOT ON THE CURRENT EDITION" and the warning that "if the blip is older, it might no longer be relevant and our assessment might be different today". It is three and a half years old, it is the best answer on the results page, and it predates everything below. What a team is actually choosing between, as of October 2026: | | Logseq OG (file version) | Logseq 2.0 (database version) | |---|---|---| | Where a graph lives | markdown files in a folder | `db.sqlite` in the graph directory | | Two people in one graph | No | Yes, over RTC | | Release status | maintained, no new features | beta, with RTC in alpha | | Multi-user cost | not offered | paid, invite only | | Access control | none | whole graph, two roles | | Licence | AGPL-3.0 | AGPL-3.0 | Neither column is the obvious answer, which is the honest finding here. One of them has your files and no teammates. The other has your teammates and a database. ## Why did Logseq split into two apps? On 24 April 2026 the Logseq team published "Big update: Logseq is splitting into two versions". The file-based app became Logseq OG, which now lives in its own repository, and the database rewrite became the main line of development. The FAQ in that post is worth reading before a team commits to either side, because it is unusually direct about what each one gets: - **Nobody is forced off the file version.** "Do I have to migrate to the database version? No. You can continue using Logseq OG (file-based) for as long as you like. There's no forced migration." - **Markdown is not going away, on that side.** "Markdown will always be supported through Logseq OG. We're committed to maintaining this for users who prefer file-based workflows." - **But OG stops moving.** "Our focus will be on maintenance and reliability rather than new feature development, allowing us to move faster on the database version." The stated support plan is security fixes, patches, and Electron and dependency upgrades. So the version that keeps your notes as files is now a maintenance project, and the version getting the work is the one that does not. The reason for the rewrite was collaboration, and the team said so two years earlier. In April 2024, explaining why the database version existed at all, founder Tienson Qin wrote that "building real-time collaboration on top of Markdown files is extremely challenging", because creating a block or renaming a page means rewriting whole files. That sentence is the premise the whole split rests on, and it is the one thing in this story worth arguing with. Hold on to it. ## What happened to the markdown files in Logseq 2.0? They are not there. This is the part most teams evaluating Logseq have not registered yet, because the marketing site still lists "Markdown files" and "Open your notes in other tools" as a product feature. Logseq's own documentation of what changed in database graphs sets out the new directory layout. A graph lives at `~/logseq/graphs/GRAPH-NAME`, and inside it: - `db.sqlite`, which "Stores all your graph's data including user configs" - `assets/`, which works as before And then one line with no softening: "`logseq/` inside a directory no longer exists." Org mode is gone too in database graphs, where "Markdown is the only supported format", meaning the markdown dialect used inside the editor rather than markdown as a storage format. The first public beta of this, Logseq 2.0.1, shipped on 13 July 2026, with 2.0.2 following in October. The project's own README is candid about where that leaves you: "The DB version is in beta status while the new mobile app and RTC is in alpha. This means that data loss is possible so we recommend automated backups or regular SQLite DB backups." ## Can you still get markdown out of a database graph? You can get a copy out. You cannot work in it, and Logseq has written down precisely why. The feature is called Markdown Mirror, and it has a published architecture decision record, ADR 0016, dated 5 May 2026 and marked Accepted. Its context paragraph states the problem plainly: "Logseq DB graphs do not expose one editable Markdown file per page in the graph directory. Some desktop workflows still need a Markdown representation that can be read by external tools, backed up, indexed, or inspected outside Logseq." The decisions it then records are the ones a team needs to read: - "Markdown Mirror is derived output. The DB remains the source of truth." - Mirror files "must be ignored by graph import, file watchers, and graph parsing so the mirror never feeds back into the graph." - "Editing files in `mirror/markdown/` does not update the graph." - "The mirror is not a backup format with guaranteed import fidelity." - "External edits to mirror files are overwritten by later Logseq edits." - Property pages "are intentionally absent from the mirror, so the output is not a complete DB export." That is a one-way export that runs on a timer, and it is correctly labelled as one. It is not the thing people mean when they say their notes are plain files. The test is simple and it fails it: open a mirror file in another editor, fix a typo, and Logseq will overwrite your fix the next time it writes that page. The export menu is the same shape. Exporting as standard markdown is documented as lossy, since it is "unlikely to ever export timestamps or all properties" and so "cannot capture all data in a graph". The EDN export is "the only export type that fully captures a graph's data and is editable", and the documentation immediately adds that it "is not yet recommended as the only means to backup a graph". Logseq has not hidden any of this. It is in their docs, their ADRs and their release notes. It is simply not in any article a team will find when they search for whether Logseq works for teams. To be fair to the roadmap: two-way sync between markdown and database graphs is still listed as planned, and the split post says so, with the caveat that "that is the plan, but we are still researching the best way to do this". It has been a roadmap line since 2024. Plan accordingly, which means not planning on it. ## How do teams share a Logseq graph today? If you are on the file version, the same three ways people have used since 2021, and each one has a known failure. **Git.** This is what the Thoughtworks blip recommended and it is still the most common answer in the forums. The detail that catches people is in Logseq's own documentation of its git integration: "Auto-commit will not automatically push changes to a remote." Logseq will build a repository in your graph folder and commit on an interval, and then stop. Pushing, pulling and merging are a script you write or a thing you remember to do. The documentation also warns against combining it with Logseq Sync, and notes that `logseq/graphs-txid.edn` should not be checked in. **A file replicator: Syncthing, Dropbox, Drive.** These work until two people edit the same page before a sync, at which point you have two finished copies and something has to reconcile them. Syncthing writes the loser to a `.sync-conflict` file, and the problem a Logseq user described in April 2024 is the one that matters: "Logseq isn't really made to open and edit random pages, you would probably not even notice that there was a .sync-conflict file, and think your edits are lost." Daily journals make this worse than it sounds, because a team's edits land in the same file on the same day. This is the same class of problem we went through for a different app in [why Obsidian sync conflicts happen](/blog/obsidian-sync-conflicts), and it is structural rather than a bug in any particular replicator. **Logseq Sync.** Worth being clear that this is not a team feature and never claimed to be. The documentation answers it as a FAQ: "Can I use Sync with other users? This isn't supported yet." The announcement post from 31 August 2024 says it in capitals: "Logseq Sync does NOT support collaboration (i.e. multiple people using the same graph at once)." There is also a single-writer rule, documented as "you can only have one device use the data at a time". On the database version there is a fourth option, and it is a real one. RTC, which the documentation describes as sync that "supports collaboration between users in real time like Google Docs", is genuinely multi-user, and it can be self-hosted. The documented caveats are that it is "a paid feature that is currently invite only" and that it is the alpha component inside a beta app. Presenting conflicts when two clients edit the same block is still an open roadmap item. ## What permissions does Logseq give a team? Close to none, and nothing per page or per folder. The file version has no concept of a user at all, so there is nothing to attach a permission to. That is not a gap in Logseq specifically. A local editor reading a folder has nothing sitting between a person and a file that could decline, which is the same reason the equivalent question has the same answer for Obsidian, covered in [can Obsidian be a team knowledge base](/blog/obsidian-team-knowledge-base). The database version does introduce people. The collaboration panel in the shipped 2.0 client lists members, invites by email address, and offers Remove access. Reading the client source rather than the documentation, because the documentation does not describe a permission model at all, the distinction it draws is between a `manager` and a `member`, over an entire graph. There is no read-only role, no per-page or per-namespace scope, no group, no SSO and no audit trail, and the roadmap as of 7 October 2026 lists no permissions work of any kind. So the unit of sharing is still the graph. Anyone you invite can read and write all of it, and your only lever is removing them. For a team with no internal boundary that is fine. For a team where the hiring notes and the deploy runbook should not have the same audience, it is the end of the evaluation. ## Does real-time editing actually cost you the files? This is the question the split leaves behind, and it is the one worth taking seriously rather than treating as settled. Logseq's answer is no, it costs you the files, and the reasoning is sound as far as it goes. Markdown on disk is a whole-file format. Real-time collaboration is built on CRDTs, whose state is an opaque binary structure, not text. Keeping both as the source of truth means reconciling two things that disagree about what a document even is, every time anyone types. Faced with that, Logseq moved the truth into the database and made markdown an export. Baalda takes the other branch, and the mechanism is the whole product rather than a feature on it. The `.md` file on disk is the durable source of truth. A watcher turns any change to that file, whether you typed it, your editor saved it or an agent rewrote a paragraph, into CRDT operations. Operations from everyone else flow back and get written into your file. Every change goes through the same CRDT as operations rather than as whole-file overwrites, which is what lets two people edit one note at once without either of them producing a second finished copy for something to merge later. Only the opaque binary updates cross the network; each device re-derives its own markdown locally. The consequences a team evaluating Logseq would care about: - **Both halves at once.** The files in the folder are the real notes, not a mirror on a timer, and more than one person can be in them live. There is no step where you choose. - **Permissions are per file and per folder.** Notes are private by default. You share a folder or a single file, with the whole team or with one person, as view or as edit. - **The AI is subject to the same thing.** An agent reaching the vault over the built-in MCP endpoint is gated by the exact same permissions as a human, so an unshared note is not reachable by asking an assistant about it instead. - **Apache-2.0, and self-hostable** on your own infrastructure. Logseq is AGPL-3.0 and also self-hostable, so on the licensing question both of these are honest answers and the comparison is about everything else. We go through the rest of it on [Baalda vs Logseq](/compare/logseq). ## Where Logseq is still the right answer Several places, and two of them are not close. **You are one person who thinks in outlines.** Logseq is an outliner and Baalda is not. Block references, block-level queries, the collapse-and-zoom structure, the daily journal as an outline that everything hangs off: none of that exists in Baalda, which is document-first. If the block graph is why you use Logseq, nothing in this post is an argument to leave, and Logseq OG is free. **You want the database version's model specifically.** A real database under a knowledge graph buys query power and rename integrity that files genuinely struggle with. Logseq is not wrong that files cost them something. They are paying for it in portability rather than in capability. **You need an importer.** There is not one. Moving an OG graph in is a file copy, because the pages really are markdown, but Logseq-flavoured syntax such as `((block-ref))` and `property:: value` arrives as literal text and nothing rewrites it for you. Moving a 2.0 database graph in is worse, because you first have to get it out, and the only lossless export is an EDN file their own docs say not to rely on as a backup. Anyone telling you a Logseq migration is a drag and drop is describing the version Logseq stopped developing. **Your whole team is allowed to read everything and you already run Git well.** Then the 2023 advice still works, the per-file permissions argument buys you nothing, and you should not pay for anything. The thing to carry out of this: the question is not whether Logseq is a good tool, because it is. It is which copy of your team's knowledge is the real one, and who is allowed to open it. If you want more on how that question sorts the open-source field generally, we wrote it up in [what makes a second brain open source](/blog/open-source-second-brain). ## FAQ ### Can Logseq be used as a team knowledge base? It depends which of the two apps you mean, and on whether everyone on the team is allowed to read everything. Logseq OG, the file version, has no multi-user mode at all, so a team runs it by replicating a folder with Git or Syncthing and accepting that two people editing one page produces two copies. Logseq 2.0 does support several people in one graph over RTC, but that is a paid, invite-only feature in alpha inside a beta app, and access is granted over the whole graph rather than per page. ### Is Logseq OG being discontinued now that the database version exists? No, but it has stopped moving. The April 2026 split announcement says "you can continue using Logseq OG (file-based) for as long as you like. There's no forced migration" and that "Markdown will always be supported through Logseq OG". The stated support plan is security fixes, patches, and Electron and dependency upgrades, because "our focus will be on maintenance and reliability rather than new feature development". So the version that keeps your notes as files is the version that is no longer getting features. ### Where does Logseq 2.0 store my notes if not in markdown files? In a single SQLite database inside the graph directory. Logseq's documentation of what changed describes `db.sqlite` as the file that "stores all your graph's data including user configs", and states that the `logseq/` directory "no longer exists". There is an opt-in Markdown Mirror that writes a derived copy to `mirror/markdown/`, but its architecture decision record is explicit that "the DB remains the source of truth", that "editing files in mirror/markdown/ does not update the graph", and that "external edits to mirror files are overwritten by later Logseq edits". ### Can I give one teammate access to only part of a Logseq graph? No. The file version has no users to attach a permission to, and the database version shares at the level of the whole graph. The shipped 2.0 collaboration panel lists members, invites by email and offers Remove access, and the client distinguishes only a manager from a member. There is no read-only role, no per-page or per-folder scope, no SSO and no audit trail, and the roadmap as of 7 October 2026 lists no permissions work. ### Is Git still a reasonable way to run a Logseq team knowledge base? It works, with two caveats people usually discover late. Logseq's built-in git support does not finish the job: its own documentation states that "auto-commit will not automatically push changes to a remote", so pushing, pulling and merging are something you script or remember. And a team's edits tend to land in the same daily journal file, which is where merge conflicts concentrate rather than in the pages you would expect. It also does not apply at all to a database graph, because a `db.sqlite` file does not produce a reviewable diff.