Obsidian vs Logseq vs Trilium: Tested Speed, Sync and MCP

Ten thousand notes is where note apps stop being interchangeable. Below that, Obsidian, Logseq and Trilium Notes all feel quick and all import your Markdown well enough. Above it, one app turns your files into a 575 MB database and drops paragraphs on the way in. Another has a plugin store eight thousand entries deep, and a third quietly syncs your whole tree to your own server in 25 seconds.

Original content from computingforgeeks.com - post 172489

This Obsidian vs Logseq vs Trilium comparison is built on a single 10,000-note vault loaded into all three apps. It covers cold start, memory, search speed, import fidelity and plugin and theme ecosystems. It also covers connecting Claude to each app over MCP, and self-hosted sync with CouchDB and the Trilium sync server. If you only want the server side, the Trilium server install and the SiYuan Docker setup cover those apps on their own. Everything below ran on Ubuntu 26.04 in October 2026 with Obsidian 1.13.7, Logseq 2.0.1 (the DB beta) and Trilium Notes 0.106.0.

Obsidian vs Logseq vs Trilium at a glance

The short version first. Every number in this table was measured on the same VM with the same vault, and the method for each one is in the next section.

Measured	Obsidian	Logseq (DB version)	Trilium Notes
Storage	Plain Markdown files	SQLite graph per vault	SQLite note tree (document.db)
Getting 10k notes in	27.15 s first index	2,400.6 s import	163.55 s import
Cold start, median of 3	4.32 s (fully indexed)	5.97 s	3.52 s
Idle memory (PSS, 120 s)	424 MB	440 MB	455 MB
On disk for a 42 MB vault	42 MB	575 MB	79 MB
Full-text search, “throughput”	3.2 s (9,408 hits rendered)	0.16 s (top 100)	1.6 s (9,408 hits)
Plugins / themes	8,294 / 855	487 / 67 in app	No store, ~143 community items
MCP	Plugin (Local REST API) plus 3rd-party servers	Built in, one session per server start	Built in, ETAPI token
Self-hosted sync	LiveSync + CouchDB, 0.46 s per edit	Needs a Logseq account	Own server, 60 s push cycle
License	Proprietary, free for work	AGPL-3.0	AGPL-3.0

Obsidian is the safe default for almost everyone. Your notes stay as files you can grep, diff and back up with anything. Pick Trilium for one server-backed knowledge base with real attributes and no plugin roulette. The Logseq DB version is the most interesting of the three and the least finished, and our import results explain why.

How we tested the three apps

Two Proxmox VMs did the work. The desktop VM (desk01) ran Ubuntu 26.04 LTS with GNOME on Wayland, 4 vCPU, 8 GB RAM and a 1920×1080 display. A second Ubuntu 26.04 VM (srv01) ran Docker for the Trilium sync server and CouchDB. All three desktop apps ran one at a time on desk01 so nothing competed for CPU.

The vault came from a small generator script with a fixed seed. It produced 10,000 Markdown notes in eight folders, with 21,933 [[wikilinks]] and 200 PNG attachments. Notes carry YAML frontmatter (tags, status, created), fenced code blocks and inline #tags. The same files went into every app through its own importer.

Each metric used one method for all three apps:

• Cold start is the launch timestamp to an app-specific “ready” check polled over the Chrome DevTools Protocol every 50 ms: for Obsidian, the metadata cache finished and links resolved; for Logseq, the graph loaded with blocks rendered; for Trilium, the tree populated. We took the median of 3 runs, with page cache dropped before each.
• Memory is the sum of Pss from /proc/<pid>/smaps_rollup across every process of the app, 120 s after the last cold start. PSS splits shared pages fairly, so three Electron apps compare honestly.
• Search used the built-in engine of each app, warm, 3 runs per query. Obsidian was timed until its search view finished rendering results. Trilium was timed at its search API. Logseq was timed at its search API with the UI default of 100 results and again with 10,000.
• MCP used Claude Code with the same three prompts per server, each in a fresh claude -p session, logging every tool call, error and the final answer.

Mobile apps were not tested on devices. That section sticks to what each project ships.

Files, a SQLite graph, or a SQLite tree

Storage is the decision that matters most. You won’t notice it until you try to leave.

Obsidian stores a vault as a folder of Markdown files plus a .obsidian config folder. Our vault was 42 MB on disk before and after Obsidian opened it. The search index lives in the IndexedDB of the app, not in the vault. Git, rsync, Syncthing, restic and grep all work on the notes directly, and nothing breaks if Obsidian disappears tomorrow.

Obsidian reads the YAML frontmatter as typed properties and builds backlinks from the files on every start:

The Logseq DB version stores each graph as a SQLite database under ~/logseq/graphs/<name>/, with separate folders for client operations and the search index. Pages are no longer files. Exports exist, and the current release adds an optional Markdown Mirror that writes a derived copy of edited pages, but the database is the source of truth. The older file-based Logseq now lives on as Logseq OG, a separate app that still reads Markdown in place.

Trilium keeps everything in one SQLite file, document.db, as a tree of notes with attributes, relations, revisions and attachments. A note can live in several places in the tree at once (cloning), and every note type (text, code, canvas, mind map, spreadsheet) sits in the same database. Backup means copying one file, and Trilium does that on a schedule by itself.

After the Obsidian import, the same note in Trilium carries its frontmatter as promoted attributes above the text:

The same 10,000 notes cost very different amounts of disk:

App	Total	Breakdown
Obsidian	42 MB	The Markdown and PNG files themselves
Logseq DB	575 MB	db.sqlite 222 MB, client-ops 209 MB, search 138 MB, assets 1.4 MB
Trilium	79 MB	document.db 74.7 MB plus a 4.3 MB WAL

The Logseq number isn’t a typo. The graph directory came out at nearly 14 times the size of the source vault. Over a third of it is the client-ops log that the DB version keeps for sync.

Logseq DB vs Logseq OG in 2026

The Logseq project split in April 2026. The Markdown, file-based app became Logseq OG, and the main repository moved to the database version, which shipped as its first stable beta in July. The roadmap still lists the DB version as “Beta testing”, Logseq Sync is invite-only and paid, and the iOS app is invite-only. The Android app has not opened for testing. If you pick Logseq today, you are picking a beta.

Importing a Markdown vault into the DB version is where that shows. Three problems surfaced, and none of them came with a warning in the app or its log.

Error: “Import failed as the file ‘logseq/config.edn’ was not found for a Logseq graph.”

Point the importer at a folder of Markdown files and it refuses. It wants a Logseq file graph, which means a logseq/config.edn next to the pages/ folder.

The fix is to create the file with the minimum content the importer accepts:

mkdir -p ~/vault10k-logseq/logseq
echo '{:meta/version 1}' > ~/vault10k-logseq/logseq/config.edn

The importer then offers its options, including how to treat tags and properties:

Plain paragraphs are dropped silently

Logseq is an outliner, and the DB importer only keeps content that is already in outline blocks (lines starting with - ). Our generated notes were ordinary Markdown paragraphs, the way Obsidian users write. The first import finished after roughly 914 s with 10,092 pages and almost every page body empty. The test page below had three paragraphs before import and none after.

We converted every paragraph into a bullet with a short script and imported again. That import took 2,400.6 s (40 minutes) from clicking Submit until the “Importing” banner cleared, for the same 10,092 pages. Links resolved and backlinks worked. Most Obsidian vaults are paragraphs, so plan on that conversion step.

YAML tag lists are split into broken tags

Frontmatter like tags: [k8s, idea] became two tags literally named [k8s and idea]. The page view shows the mangled names in Linked references (#k8s], #[review), while native tags:: k8s, idea properties imported correctly. Inline #tags were removed by the default import option.

None of this is a reason to dismiss the DB version. Properties became typed fields, links became real references, and queries are fast. It is a reason to test your own vault on a copy before you commit.

Performance with 10,000 notes

Getting the vault in was the biggest difference. Obsidian simply opened the folder and finished indexing 22,133 resolved links in 27.15 s. The Trilium built-in Obsidian importer took 163.55 s and produced 10,018 text notes, 21,930 internal-link relations and the image attachments, with tags turned into labels and frontmatter into promoted attributes. Logseq took 40 minutes for the bulleted vault.

Trilium has a trap here. Uploading the same zip through ETAPI (POST /etapi/import) produced 10,009 file notes instead of text notes. The ETAPI import path doesn’t apply the text-import options. Use the importer in the app.

Cold start and memory were close enough that none of them is a reason to pick an app:

Metric	Obsidian	Logseq DB	Trilium
Window ready, median	2.64 s	5.97 s	3.52 s
Fully indexed, median	4.32 s	same as above	same as above
Idle PSS at 120 s	424 MB (6 processes)	440 MB (8 processes)	455 MB (6 processes)

The Logseq start time barely moved between the paragraph-less graph (5.67 s) and the full one (5.97 s). The DB loads pages lazily, which is the main thing the database bought it.

Search is where the engines differ in kind. The hit counts agree between Obsidian and Trilium. Both found 9,408 notes containing “throughput”, so they searched the same content:

Query	Obsidian (UI, all hits)	Trilium (API, all hits)	Logseq (top 100)	Logseq (up to 10,000)
throughput	3,215 ms / 9,408	1,602 ms / 9,408	157 ms	3,079 ms
ingress certificate	1,851 ms / 8,872	1,676 ms / 8,872	89 ms	4,972 ms
05041 (rare)	197 ms / 7	880 ms / 6	91 ms	98 ms

Logseq feels fastest because its search box only fetches the top 100 blocks. Raise the limit to 10,000 and it slows to 3.1 to 5.0 s on common words. That is the slowest result on the two-word query. The results also stop at the 10,000 cap. The Obsidian figure includes rendering thousands of result rows, so a narrow query returns in under 200 ms. Trilium search costs a steady 0.9 to 1.7 s at this size, even for a rare token.

Obsidian also handled the full graph view of all 10,005 nodes without complaint:

Plugins, themes and plugin security

The Obsidian catalogue is the reason many people stay. The community list held 8,294 plugins and 855 themes on the test day, and the in-app browser showed the same 8,294.

Look closely at that grid. Calendar was last updated five years ago, Kanban and Style Settings two years ago, and Dataview more than a year ago, yet they are still among the most installed. Popular doesn’t mean maintained. Check the repository before you build a workflow on a plugin.

Plugins run with full access to your vault and your machine. In April 2026 Elastic documented a campaign that abused two legitimate community plugins in a shared cloud vault. Victims were told to enable community-plugin sync. The vault then ran a loader. On Windows it installed the PHANTOMPULSE remote access trojan. On macOS it ran an AppleScript dropper. Obsidian has since added automated security scans for every plugin version, and the browser now flags plugins that have not been manually reviewed. The first time you open a vault that ships plugins, Obsidian asks whether you trust its author. Say no to vaults you did not create.

The Logseq marketplace listed 487 plugins and 67 themes inside the DB app, against 562 and 69 in the marketplace repository, and only 124 packages declare DB support. The marketplace opens with a blunt warning that plugins can read your graph and local files and issue network requests.

Trilium has no plugin store at all. Extensions are scripts and widgets written as notes inside your own database, plus themes. The community list, awesome-trilium, has about 143 entries. The server build ships with backend scripting disabled, which is a sensible default. For most Trilium users the built-in note types (canvas, mind map, kanban, calendar, geo map, spreadsheets) replace what Obsidian users install plugins for.

Connect Claude to Obsidian, Logseq and Trilium over MCP

All three can now be driven by an AI agent through the Model Context Protocol. This is where the gap between “has MCP” and “works with MCP” showed up. If you are new to MCP in Claude Code, the Claude Code MCP setup guide covers scopes and config files, and MCP vs RAG vs agent skills explains when an MCP server is the right tool.

Every server got the same three prompts, each in a fresh session. First, list every note that links to Restore pod 05041 (three notes in the source vault, plus any test notes that earlier servers had created by linking to it). Second, create a new note that links to it. Third, append a line to the journal note for today. Each config below was loaded with claude -p "<prompt>" --mcp-config <file> --strict-mcp-config --allowedTools "mcp__<server>". Print mode denies MCP tools that are not pre-approved. Keep the --allowedTools flag.

MCP server	Tools	Backlinks	Create linked note	Journal append	Tool calls
Obsidian: Local REST API (built-in MCP)	20	Correct	Pass	Pass	3 / 3 / 4
Obsidian: mcp-obsidian	15	Correct	Pass	Pass after 2 errors	7 / 2 / 7
Obsidian: mcpvault (files direct)	18	Correct after 2 errors	Pass	Pass	8 / 3 / 6
Logseq: built-in	6	Correct	Pass	Pass	5 / 2 / 4
Logseq: mcp-logseq	17	Wrong (“No notes link”)	Pass	Pass	2 / 2 / 6
Trilium: built-in	23	Correct	Pass	Pass, wrong place	4 / 3 / 14
Trilium: triliumnext-mcp	19	Correct	Pass	Pass, real day note	7 / 3 / 3

Each task cost between $0.05 and $0.21 in tokens on Claude Sonnet. The full per-call logs are in the lab notes.

Obsidian: the Local REST API plugin is the MCP server

Obsidian has no official MCP server. The community plugin Local REST API now includes one at /mcp/, and both the popular mcp-obsidian server and the endpoint built into the plugin depend on it. Install it from the community browser, enable it, and copy the API key from its settings.

The plugin serves HTTPS on port 27124 with its own certificate authority. Claude Code refused that endpoint with a “name constraint error” and UNSUPPORTED_CONSTRAINT_TYPE, even with the CA added through NODE_EXTRA_CA_CERTS. The CA carries a critical name constraint limited to 127.0.0.1 and localhost, which plain Node accepted and the TLS stack in Claude Code did not. The plugin documents a plain HTTP listener on 27123 for this case. Turn it on in the plugin settings with “Enable HTTP server”, and it answers on loopback only.

The working config, with the key replaced:

{
  "mcpServers": {
    "obsidian": {
      "type": "http",
      "url": "http://127.0.0.1:27123/mcp/",
      "headers": {
        "Authorization": "Bearer your-obsidian-api-key"
      }
    }
  }
}

mcp-obsidian (4,457 GitHub stars) wraps the same REST API as 15 tools and talks to the HTTPS port without complaint, because its Python client sets verify_ssl=False by default. It pins mcp<2.0, so run it with uvx rather than installing it into an environment that already has the newer SDK:

{
  "mcpServers": {
    "mcp-obsidian": {
      "type": "stdio",
      "command": "uvx",
      "args": ["mcp-obsidian"],
      "env": {
        "OBSIDIAN_API_KEY": "your-obsidian-api-key",
        "OBSIDIAN_HOST": "127.0.0.1",
        "OBSIDIAN_PORT": "27124"
      }
    }
  }
}

Its periodic-note tool returned Error 40400: Not Found twice during the journal task, because the Daily notes core plugin was not configured. Claude recovered by listing the journal folder. mcpvault takes the opposite approach: it reads the vault folder directly, needs no plugin and no running Obsidian, and suits headless machines.

Logseq: built in, but one session per server start

The Logseq DB version has its MCP server under Settings, AI. It depends on the HTTP API server, which you enable under Features. After a restart an “API” button appears in the header, where you add an authorization token and start the server on 127.0.0.1:12315.

The first test run failed all three tasks with a connection timeout. The app log explained why. In the current stable build, every MCP session after the first one fails with Already connected to a transport, and the HTTP request returns headers and then hangs. Our own curl probe had used up the only session.

Logseq fixed this upstream on 18 August 2026 (“build a fresh MCP server per session”), but no stable release carries the fix yet. Until one does, stop and start the API server from the header menu before each new agent session. With that bounce before every task, the built-in server passed all three. Use this config:

{
  "mcpServers": {
    "logseq": {
      "type": "http",
      "url": "http://127.0.0.1:12315/mcp",
      "headers": {
        "Authorization": "Bearer your-logseq-token"
      }
    }
  }
}

Two more things matter here. The HTTP API only checks tokens once at least one token exists, so create one before you start the server. And the third-party mcp-logseq backlinks tool returned nothing on the DB graph, which led Claude to answer “No notes link to Restore pod 05041” when four did. Those were the three originals plus the note the built-in server had created minutes earlier. A wrong answer delivered confidently is worse than an error.

Trilium: built in and the most complete

The Trilium MCP server sits under Options, AI / LLM, behind the “AI features” switch. It exposes 23 tools, requires an ETAPI token on every request (loopback included), and rate-limits failed authentication to 10 attempts per 15 minutes per IP. The options page prints a ready-made Claude Code command.

Create the token under Options, ETAPI, then point Claude at the local server inside the desktop app:

{
  "mcpServers": {
    "trilium": {
      "type": "http",
      "url": "http://127.0.0.1:37840/mcp",
      "headers": {
        "Authorization": "Bearer your-etapi-token"
      }
    }
  }
}

Backlinks and the linked note were right first time. The journal task took 14 tool calls, because our database had no calendar root, so Claude settled on a note named 2026-10-01 inside the imported journal folder. perfectra1n/triliumnext-mcp, built from source, has a get_special_note tool that created a proper calendar day note in 3 calls. It also noticed that the link written by the built-in server existed only as HTML and had not become a relation, so the app counts three backlinks, not the four you would expect with that test note included.

Whichever app you connect, the token is full read and write access to every note. Treat it like a password. The stateless MCP migration notes show why session-bound servers like the Logseq one break in exactly this way.

Self-hosted sync, tested

Obsidian Sync and Logseq Sync are paid services. The Trilium sync server is the app itself. We self-hosted what could be self-hosted on srv01, behind Caddy with TLS, and timed each one.

Obsidian LiveSync with CouchDB

Self-hosted LiveSync (12,631 GitHub stars, MIT) replicates the vault through CouchDB with end-to-end encryption. Create the project folder and the admin credentials on the server:

mkdir -p ~/livesync/{couchdb-data,couchdb-etc,caddy-data}
cd ~/livesync
echo "COUCHDB_USER=obsadmin" > .env
echo "COUCHDB_PASSWORD=$(openssl rand -hex 16)" >> .env
chmod 600 .env

Open the compose file:

vim ~/livesync/compose.yaml

The exact file that ran follows. CouchDB is not published on the host, so only Caddy faces the network:

services:
  couchdb:
    image: couchdb:3.5.2.1
    restart: unless-stopped
    env_file: .env
    volumes:
      - ./couchdb-data:/opt/couchdb/data
      - ./couchdb-etc:/opt/couchdb/etc/local.d
  caddy:
    image: caddy:2.11.4
    restart: unless-stopped
    ports:
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - ./caddy-data:/data

Now the Caddyfile:

vim ~/livesync/Caddyfile

It fronts CouchDB and the Trilium sync server from the next section. The lab used the Caddy internal CA because the names only exist on the LAN. With a public DNS name, delete the tls internal lines and Caddy fetches a Let’s Encrypt certificate on its own:

couch.home.arpa {
	tls internal
	reverse_proxy couchdb:5984
}

trilium.home.arpa {
	tls internal
	reverse_proxy trilium-sync-trilium-1:8080
}

CouchDB runs as UID 5984, and the LiveSync guide hands both data folders to that user. Fix ownership, then start the stack:

sudo chown -R 5984:5984 couchdb-data couchdb-etc
docker compose up -d

The LiveSync provisioning script now needs Deno 2, and the Deno installer needs unzip (sudo apt install -y unzip on a minimal image). The script sets the CouchDB options LiveSync expects (single node, CORS, request size limits) and creates the database:

curl -fsSL https://deno.land/install.sh | sh -s -- -y
export PATH=$HOME/.deno/bin:$PATH
set -a; . ./.env; set +a
CIP=$(docker inspect -f "{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}" livesync-couchdb-1)
export hostname=http://$CIP:5984 username=$COUCHDB_USER password=$COUCHDB_PASSWORD database=obsidiannotes
curl -s https://raw.githubusercontent.com/vrtmrz/obsidian-livesync/main/utils/couchdb/couchdb-init.sh | bash

After a long dependency download, the script ends with one line:

CouchDB provisioning completed.

Rather than typing server details into every device, generate a setup URI on the server. It carries the connection settings and the end-to-end encryption passphrase, encrypted with a one-time passphrase of its own:

openssl rand -hex 12 > .e2ee && chmod 600 .e2ee
export hostname=https://couch.home.arpa passphrase=$(cat .e2ee)
deno run --minimum-dependency-age=0 -A https://raw.githubusercontent.com/vrtmrz/obsidian-livesync/main/utils/flyio/generate_setupuri.ts

The output, with secrets redacted, gives a URI that is valid for a week:

Generated couchdb Setup URI.
Ephemeral: usable until 2026-10-08T00:00:00.000Z (UTC).
Your passphrase for the Setup URI is: <secret>
This passphrase is never shown again, so store it safely.
ID recovery code: sls-id-v1:<secret>
Use id_recovery_code with this value and reuse the same remote settings when generating another Setup URI for the same Vault.
obsidian://setuplivesync?settings=<redacted>

Clients must trust the certificate. With the Caddy internal CA, export its root from the container on the server, then copy ~/caddy-root.crt to each desktop with scp:

cd ~/livesync
docker compose exec -T caddy cat /data/caddy/pki/authorities/local/root.crt > ~/caddy-root.crt

On each desktop, add the root to the system store and to the NSS store that Electron reads on Linux. Then make the names resolve:

echo "10.0.1.50 couch.home.arpa trilium.home.arpa" | sudo tee -a /etc/hosts
sudo cp caddy-root.crt /usr/local/share/ca-certificates/caddy-lab-root.crt
sudo update-ca-certificates
sudo apt install -y libnss3-tools
mkdir -p ~/.pki/nssdb
[ -f ~/.pki/nssdb/cert9.db ] || certutil -d sql:$HOME/.pki/nssdb -N --empty-password
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n caddy-lab-root -i caddy-root.crt

Install Self-hosted LiveSync from the community browser and open the setup URI. Obsidian validates it and asks for the URI passphrase.

The first device initialises the remote and every other device joins it:

Initialising from the 10,000-note vault took 366 s after the final confirmation. About half of that was LiveSync building its local database (the status bar counts “Processing: x/10204”) before the first document reached CouchDB at 184 s. The server held 51,156 documents and 186 MB when the upload finished. Within about 45 minutes, automatic compaction in CouchDB had brought it down to 56 MB.

A second, empty vault joined in two phases. Downloading 48.72 MB took 89 s, then writing the 10,204 files took until 716 s, close to 12 minutes in total. diff -rq against the source vault found no differences. Live edits were the best result in this article. With LiveSync mode on, a change in one vault was readable on disk in the other in 0.43 to 0.63 s (median 0.46 s over four runs). The first edit took 12.1 s while the receiver was still catching up.

Two traps cost us time. Killing Obsidian after the upload left flag_rebuild.md in the vault, so the next start offered to overwrite the server again. Do not confirm that dialog. Close Obsidian normally, or delete the flag file once the server holds your data. The wizard also left every sync trigger off (LiveSync, periodic, on save, on start) until we finished its last step. If the status bar shows ⏹ instead of ⚡, open the plugin settings and pick a sync mode.

Trilium desktop to a Trilium server

The Trilium server is the same app in a container. The desktop can push its whole database into a fresh, uninitialised server, which is the cleanest way to start. This compose file joins the network of the Caddy stack above:

vim ~/trilium-sync/compose.yaml

Keep the server image tag identical to the desktop version, because both ends check the sync protocol version:

services:
  trilium:
    image: triliumnext/trilium:v0.106.0
    restart: unless-stopped
    volumes:
      - ./data:/home/node/trilium-data
networks:
  default:
    name: livesync_default
    external: true

Start it with docker compose up -d. Until a client claims it, the server answers "isInitialized":false with no authentication. Anyone who reaches it first can take it over, so never expose a new Trilium server to the internet before you initialise it.

On the desktop, open Options, Sync, enter https://trilium.home.arpa and click “Test now”. The desktop initialised the server with its own password and pushed 114,557 changes in 115 batches in 25 s. One request failed with 401 Logged in session not found mid-sync, the client retried, and the closing content-hash check passed.

After that, Trilium syncs on a fixed 60-second cycle. Our five edits reached the server in 17.7 to 55 s, so plan on up to a minute. One more detail: ETAPI tokens are synced like notes. A token created on the desktop also works against the server, so revoke tokens in one place and they are gone everywhere. The server adds OpenID Connect and TOTP sign-in, but it is still one user per instance.

Logseq: the server is open source, the login is not

The DB app has a “Sync Server URL” field under Settings, Advanced. The Node adapter for its sync server is open source. We did not get further than the README. The adapter validates logins against Amazon Cognito (COGNITO_ISSUER, COGNITO_CLIENT_ID, COGNITO_JWKS_URL), and the documented example uses the user pool run by Logseq. In practice your clients still log in with a Logseq account. You also build the server from source with Clojure and pnpm.

Mobile apps

Obsidian ships native iOS and Android apps that open the same vault format, and Obsidian Sync or LiveSync keeps them current. The new Logseq iOS app for DB graphs is invite-only, and the Android app has not opened for testing. Logseq OG still publishes an Android APK on its release page. Trilium has no native mobile app. The project closed its official mobile app milestone as not planned in May 2026. It points to the mobile web frontend that the server serves to phone browsers, so you need a reachable server.

Freelancers, employees and teams

The licence question is settled. Obsidian has been free for work since February 2025. The $50 per user per year commercial licence is optional. Logseq and Trilium are AGPL-3.0 and free for any use.

For a freelancer, client separation is the real requirement. Obsidian handles it with one vault per client. Each vault can be its own Git repository or LiveSync database, so handing a client their notes is a folder copy. Logseq does the same with one graph per client. Trilium keeps everything in one database. Hoisting a client subtree and protected notes help, but handing over the notes for one client cleanly means an export.

Employees should check what their company allows before the tooling question. Obsidian with plain files fits most data-handling policies. The notes sit on a managed laptop and sync through whatever the company already approves. A self-hosted Trilium server keeps data in your own infrastructure, which helps with residency rules. Logseq DB sync is a hosted, invite-only service, which most security reviews will not clear today.

Teams are where all three fall short of a wiki. Obsidian Sync shared vaults cap at 20 collaborators. Everyone gets the same permissions as the owner, and there is no live co-editing. Sync costs $4 (Standard) or $8 (Plus) per user per month billed annually. Trilium has no multi-user support yet, so a team server would be one shared account. Real-time collaboration in Logseq exists only inside its paid sync. For shared team documentation, a wiki such as Outline is the better tool, with personal notes kept in one of these three.

Obsidian vs Logseq, Trilium vs Obsidian, Logseq vs Trilium

Obsidian vs Logseq

Choose Obsidian if you write in paragraphs, want your notes as files, or need a plugin for something specific. Choose Logseq if you think in outlines and daily journals. Its database makes typed properties and queries fast. Moving from Obsidian to Logseq DB means converting paragraphs to bullets and fixing tags. Moving back means an export, because the DB version no longer works on your files.

Trilium vs Obsidian

Trilium wins if you want one structured knowledge base without curating plugins. It brings attributes, relations, cloning, many note types and your own sync server. Obsidian wins on portability, ecosystem size and mobile apps. It also syncs edits faster: 0.46 s with LiveSync against the 60 s Trilium cycle. The Trilium Obsidian importer was the best migration path we tested: 21,930 of 21,933 links survived.

Logseq vs Trilium

Both are AGPL databases with built-in MCP. Trilium is mature, imports Obsidian vaults cleanly, and its server sync works today without a third-party account. The Logseq DB version has the better outliner and journal workflow. It is also a beta with import gaps and a 575 MB footprint for our vault. Its sync depends on the Logseq service. For a self-hoster today, Trilium is the safer of the two.

GitHub tooling worth installing

A few projects change how these apps fit into an engineering workflow. Star counts are from the test day:

• kepano/obsidian-skills (49,074 stars): agent skills that teach Claude and other coding agents to use the Obsidian CLI and Obsidian Markdown properly. Pair it with the official Obsidian CLI, which needs the app running.
• jackyzha0/quartz (13,320): publishes an Obsidian vault as a static site with backlinks and graph, the free alternative to Obsidian Publish.
• Yakitrak/notesmd-cli (1,591): a community Obsidian CLI that works on the vault without the app.
• zoni/obsidian-export (1,336): converts a vault to standard Markdown, resolving wikilinks and embeds, for exit plans and static sites.
• obsidianmd/obsidian-headless (236): an official headless client for Obsidian Sync, so servers can pull a vault without a desktop session.
• logseq/publish-spa (313): publishes a Logseq graph as a single-page app from a GitHub Action.
• Nriver/trilium-py (232): a Python client for the Trilium ETAPI, the quickest way to script imports and reports. Remember the ETAPI import trap above.
• Nriver/awesome-trilium (953): the index of Trilium themes, widgets and scripts, since there is no store.

To wire these into Claude on a Linux desktop, the Claude Desktop and Claude Code install guide covers both clients.

Pick by how you work

Pick Obsidian if you want notes that outlive the app. It had the smallest footprint (42 MB, the files themselves) and the biggest ecosystem (8,294 plugins). It started in 4.32 s on 10,000 notes and synced edits in under a second over your own CouchDB. Budget an hour for LiveSync and run MCP over the HTTP port of the plugin.

Pick Trilium if you want one self-hosted knowledge base for yourself. Its importer kept 21,930 of 21,933 links, its server took the full 10,000-note push in 25 s, and its built-in MCP was the most complete of the three. Accept a one-minute sync delay and no native mobile app.

Pick the Logseq DB version if outlining and journals are how you think and you are comfortable on a beta. Convert paragraphs to bullets before import, expect a graph roughly 14 times the size of your Markdown, and bounce the API server before each MCP session until a fixed release ships. If you want Logseq without the beta, Logseq OG still reads your Markdown files in place.