SiYuan review: block-based Obsidian alternatief voor developers

SiYuan Review: een op blokken gebaseerd Obsidian alternatief voor ontwikkelaars

Ik heb op woensdagmiddag mijn Obsidian-kluis kapot gemaakt, en de manier waarop deze kapot ging, is de reden dat ik op zoek ging naar iets anders.

Ik was twee jaar aan aantekeningen aan het herwerken. Een map met de naam bug-logs/ was uitgegroeid tot 312 bestanden en ik wilde deze opsplitsen per project: bug-logs/laravel/, bug-logs/react/, bug-logs/infra/. Standaard opruimen. Iets wat elke ontwikkelaar doet als een platte map in een moeras verandert.

Ik verplaatste 47 bestanden in één batch, zag hoe Obsidian ze hernoemde en ging koffie zetten. Toen ik terugkwam, opende ik een runbook dat ik zes maanden eerder had geschreven: een stapsgewijs hersteldocument voor een productie-incident dat ik nooit meer wilde herhalen. De derde stap gekoppeld aan een buglogboek genaamd redis-eviction-storm-debug.md. De link weergegeven als platte tekst. Klik deed niets.

Ik heb het bestand gecontroleerd. Het bestond. Het bevond zich in de nieuwe map bug-logs/infra/. Het blok waar ik naar verwees – het specifieke gedeelte waarin de uitzettingsconfiguratie werd uitgelegd die de cascade in gang had gezet – stond daar, onaangeroerd. Maar de link was dood omdat het pad was veranderd en de blokreferentie was verankerd in een pad-plus-kopcombinatie die niet langer overeenkwam.

Dat was het moment waarop ik besefte dat mijn tweede brein een structureel probleem had. Niet precies de schuld van Obsidian. Markdown-bestanden plus bestandssysteempaden plus kop-verankerde blokkoppelingen - dat is het contract. Als je dingen verplaatst, accepteer je dat sommige referenties kapot gaan. Voor een persoonlijk dagboek, prima. Voor documentatie vertrouw ik op 2 uur 's nachts tijdens een incident, niet goed.

Dus begon ik voorbij Obsidian te kijken. Het volgende dat ik testte was SiYuan, een open-source, local-first kennisbeheertool waarop versie 3.6.5 draait vanaf 21 april 2026. Het blokkeert verwijzingen op een andere manier: elk blok heeft een permanente ID die verplaatsingen, hernoemingen, refactoren en alles behalve verwijdering overleeft. Dat klonk als precies wat mijn kapotte runbook nodig had.

Dit is het eerlijke schrijven. Wat werkte. Wat ervoor zorgde dat ik naar de terugknop reikte. Of het nu een permanent plekje in de ontwikkelaarsstapel verdient in 2026, of dat de vergelijking SiYuan vs Obsidian voor de meeste mensen altijd teruggaat naar Obsidian. Spoiler: het antwoord hangt af van wat voor soort aantekeningen je daadwerkelijk bewaart.

Waarom ik in de eerste plaats voorbij Obsidian ging kijken

Obsidian heeft mij vier jaar lang gediend. Ik ben hier niet om het te begraven. De meer dan 230 berichten op deze site verwijzen voortdurend naar Obsidian omdat het voor de gebruikssituatie is ontworpen voor – een snel, platte tekst, met plug-ins uitbreidbaar tweede brein – er gaat bijna niets boven.

Maar mijn aantekeningen evolueerden. Ze stopten met ‘hardop denken’ en veranderden in gestructureerde artefacten:

• Buglogboeken met reproduceerbare stappen, analyse van de hoofdoorzaak en verificatie van oplossingen
• Architectuurbeslissingsrecords (ADR's) met expliciete context, beslissing en consequenties
• Runbooks voor productie-incidenten met opeenvolgende herstelstappen
• Aantekeningen over klantbetrokkenheid met gekoppelde buglogboeken, beslissingen en runbooks
• Langlopende projectdocumentatie met meerdere bijdragers (ik + subagenten die geheugenbestanden schrijven)

Zodra uw aantekeningen meer op een documentatiesysteem lijken dan op een dagboek, beginnen drie Obsidian-beperkingen te knarsen:

1. Blokreferenties worden verbroken bij refactoring. De blokreferentiesyntaxis van Obsidian ([[file#^block-id]]) verankert aan een specifiek blok-ID in een specifiek bestand. Wanneer u het bestand verplaatst, probeert Obsidian het pad automatisch bij te werken. Meestal werkt het. Soms is dit niet het geval, vooral bij batchverplaatsingen, door plug-ins geïntroduceerde syntaxis of externe editorsynchronisatie. En als het stilzwijgend mislukt, merk je het pas nadat je zes maanden later op een link klikt.

2. Voor query's in databasestijl zijn plug-ins vereist. Dataview is briljant. Het is ook een community-plug-in die wordt onderhouden door één ontwikkelaar en die ongeveer twee keer per jaar grote Obsidian-releases doorbrengt. Als uw runbook afhankelijk is van een correcte weergave van een Dataview-query, is uw runbook ervan afhankelijk of Dataview in orde is. Dat is een kwetsbare afhankelijkheidsketen voor productiekritische documenten.

3. Bewerken door meerdere gebruikers is niet het juiste model. Obsidian Sync bestaat, en is solide voor persoonlijk gebruik. Maar Obsidian is ontworpen als een tool voor één gebruiker. Op het moment dat je wilt dat een team of subagenten tegelijkertijd in dezelfde kluis schrijven, vecht je tegen het model.

Het cracked-link-incident was slechts het oppervlak. Daaronder zat een dieper besef: mijn aantekeningen waren het markdown-bestand-als-document-model ontgroeid. Ik had een systeem nodig waarbij de atomaire eenheid het blok was, en niet het bestand. Waar referenties structuurveranderingen overleefden. Waar zoekopdrachten native waren en niet vastgeschroefd.

Dat is de niche waar SiYuan vs Obsidian eigenlijk voor vecht.

Wat Block IDs eigenlijk doet – een echt voorbeeld

De toonhoogte: elk blok in SiYuan krijgt een permanente ID van 22 tekens op het moment dat u het maakt. De ID blijft voor altijd bij het blok – bij verplaatsingen, hernoemen, splitsen van documenten en samenvoegen van documenten. Verwijzingen verwijzen naar de ID, niet naar het pad. Verplaats het blok; de referentie werkt nog steeds.

Klinkt in theorie leuk. Zo ziet het er in de praktijk eigenlijk uit.

Ik heb een document gemaakt met de naam redis-eviction-storm.md en drie blokken geschreven:

- Symptom: Redis CPU spikes to 100% for 90 seconds, then recovers.
- Root cause: maxmemory-policy set to allkeys-lru with eviction batch
  size of 10. Under high write load, eviction cycle blocks the event loop.
- Fix: Switch to allkeys-lfu, raise hz to 50, set maxmemory-eviction-tenacity to 5.

SiYuan sloeg elke kogel op als een afzonderlijk blok. Toen ik op het tweede opsommingsteken klikte, liet de editor me de blok-ID zien, zoiets als 20260418142733-x7k9j2m. Dat is een tijdstempel van 14 cijfers (20260418142733 = 18 april 2026, 14:27:33) plus 7 willekeurige tekens. Elk blok in uw werkruimte krijgt er één.

Ik heb de blokreferentie gekopieerd en in een ander document geplakt: een runbook met de naam incident-recovery-redis.md. De verwijzing wordt weergegeven als een klikbare insluiting waarin de tekst van de hoofdoorzaak inline wordt weergegeven. Toen deed ik het destructieve ding dat Obsidian kapot maakte: ik verplaatste het brondocument naar een diep geneste map, hernoemde het naar infra/databases/redis/eviction-storm-2026.md en splitste het in twee afzonderlijke documenten.

De verwijzing in mijn runbook werkte nog steeds. Niet "werkte na herindexering." Niet "werkte nadat de plug-in de paden had afgestemd." Werkte meteen, omdat de referentie gebonden was aan de blok-ID en niet aan het bestandspad. De onderliggende opslag is een .sy JSON-bestand met een AST-knooppuntboom, en de blok-ID is de AST-knooppunt-ID. Verplaats het document, het bestand beweegt; de JSON-knooppunt-ID's blijven ongewijzigd. SQLite indexeert het bestandspad opnieuw, de referentieresolutielaag zoekt het blok op op ID, vindt het in het nieuwe bestand en geeft het weer.

Dit is de enige functie die voor mij het bestaan ​​van SiYuan rechtvaardigt. Als u ooit een blokreferentie naar een refactor bent kwijtgeraakt, weet u precies hoeveel dat ertoe doet.

De afweging zit in de bestandsindelingslaag, en we komen er nog op terug — omdat .sy JSON niet Markdown is, en dat heeft gevolgen.

De killer-functie: Native SQL-query's in notities

Obsidian-gebruikers bereiken Dataview. Notion-gebruikers bouwen relationele databases handmatig. SiYuan wordt geleverd met een SQLite-database die elk blok in uw werkruimte indexeert, en u schrijft SQL rechtstreeks in notities.

Geen plug-in. Geen zijbalktool. De query leeft inline als een insluitblok, wordt uitgevoerd wanneer het document wordt weergegeven en wordt bijgewerkt wanneer de onderliggende gegevens veranderen.

Hier is een echte vraag die ik bovenaan mijn bug-tracker.md-document bewaar. Het haalt elk blok met de tag #bug-open over mijn hele werkruimte, gesorteerd op aanmaakdatum:

SELECT
  '[' || b.content || '](siyuan://blocks/' || b.id || ')' AS bug,
  b.hpath AS document,
  datetime(substr(b.created, 1, 4) || '-' ||
           substr(b.created, 5, 2) || '-' ||
           substr(b.created, 7, 2)) AS opened
FROM blocks AS b
WHERE b.tag LIKE '%#bug-open%'
ORDER BY b.created DESC
LIMIT 50

Er zijn drie dingen die goed gaan die Dataview nooit voor mij heeft gedaan:

Het is echte SQL. Geen DSL die SQL met zijn eigen eigenaardigheden omhult. Als u in uw carrière een SELECT heeft geschreven, kunt u vanaf dag één SiYuan-query's schrijven. Sluit zich aan bij het werk. Subquery's werken. CTE's werken. Het schema is gedocumenteerd en stabiel: blocks is de hoofdtabel, met kolommen als id, content, type, path, hpath, root_id, tag, created, updated, markdown en nog een paar.

Het schema is zichtbaar. De API-documentatie van SiYuan vermeldt expliciet het blocks-tabelschema. Er is ook een /api/query/sql HTTP-eindpunt dat een JSON-tekst zoals {"stmt": "SELECT * FROM blocks WHERE content LIKE '%redis%' LIMIT 7"} gebruikt en rijen retourneert. Dat betekent dat externe scripts, agenten of zelfs Claude Code zelf rechtstreeks uw kennisbank kunnen bevragen zonder de markdown-bestanden te parseren.

Insluitingsblokken zijn eersteklas. Elk insluitingsblok in SiYuan begint met select * from blocks. Dat is de conventie omdat de insluitingsrenderer het blokschema nodig heeft om te weten hoe resultaten moeten worden weergegeven. De query wordt bijgewerkt wanneer het document wordt geladen, wanneer gegevens worden gewijzigd en wanneer handmatig wordt vernieuwd.

Ik heb nu query's ingebed in mijn werkruimte:

• Een dashboard bovenaan mijn projectdocument waarin elk TODO-blok in de subboom van het project wordt vermeld
• Een 'oude notities'-zoekopdracht die elk document naar voren brengt dat ik al meer dan 90 dagen niet heb bijgewerkt
• Een zoekopdracht per bug die open bugs groepeert op basis van #sev1-, #sev2- en #sev3-tags
• Een 'vandaag'-query in mijn dagelijkse notitie die elk blok ophaalt dat ik die dag heb gemaakt of gewijzigd

Dataview kan het meeste hiervan doen. Het verschil is dat de querylaag van SiYuan deel uitmaakt van het kernproduct en niet een community-plug-in is die wordt onderhouden door één heroïsche ontwikkelaar. Het schema is stabiel. De query-engine is SQLite, de saaiste betrouwbare databasesoftware die er bestaat. Ik vertrouw erop voor productiekritieke documenten op een manier waarop ik Dataview nooit helemaal vertrouwde.

Docker Zelfhost-walkthrough — De installatie van 2026

SiYuan draait als desktop-app op macOS, Windows en Linux. Het werkt ook als een Docker-container, en zo host ik mijn belangrijkste werkruimte — op een kleine VPS, toegankelijk vanaf elk apparaat, volledig onder mijn controle.

De officiële Docker-afbeelding is b3log/siyuan op Docker Hub. De standaardpoort is 6806. Het minimale commando om een werkruimte actief te krijgen:

docker run -d \
  --name siyuan \
  -p 6806:6806 \
  -v /opt/siyuan/workspace:/siyuan/workspace \
  -e PUID=1000 \
  -e PGID=1000 \
  -e TZ=Asia/Dhaka \
  b3log/siyuan \
  --workspace=/siyuan/workspace/ \
  --accessAuthCode=replace-with-a-strong-password

Drie dingen in die opdracht zijn van belang en zijn niet duidelijk uit de documentatie:

De vlag --workspace moet overeenkomen met het mountpad aan de containerzijde. SiYuan slaat alles op in de werkruimtemap: uw notebooks, de SQLite-index, bijlagen, plug-ingegevens, synchronisatiemetagegevens. Als de vlag en de volumeaankoppeling het niet eens zijn, start de container maar schrijft niets nuttigs naar de schijf, en bij het opnieuw opstarten verliest u de status.

--accessAuthCode is je wachtwoord. Het is het enige dat tussen poort 6806 en iedereen die je VPS kan bereiken staat. Gebruik een lange willekeurige reeks. Behandel het als een SSH-sleutel. Als u het vergeet, moet u de container stoppen, de configuratie in de werkruimtemap bewerken en opnieuw opstarten.

PUID/PGID komt overeen met uw hostgebruiker. Zonder deze schrijft de container bestanden als root, en wanneer u SSH gebruikt om een ​​back-up te maken van de werkruimte, kunt u uw eigen gegevens niet lezen zonder sudo. Voer id -u en id -g uit op uw host en geef deze waarden door.

Docker Compose-versie, wat ik feitelijk gebruik:

version: "3.9"
services:
  siyuan:
    image: b3log/siyuan
    container_name: siyuan
    restart: unless-stopped
    ports:
      - "127.0.0.1:6806:6806"
    volumes:
      - /opt/siyuan/workspace:/siyuan/workspace
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Asia/Dhaka
    command:
      - --workspace=/siyuan/workspace/
      - --accessAuthCode=${SIYUAN_AUTH_CODE}

Let op de binding op 127.0.0.1:6806: ik stel poort 6806 nooit rechtstreeks bloot aan het openbare internet. NGINX loopt voorop met TLS, basisauthenticatie als tweede laag en een strikte toelatingslijst voor IP's die de upstream kunnen bereiken. Dat is dezelfde houding die ik zou aannemen bij elke zelfgehoste productiviteitstool, en het is iets dat mijn checklist voor beveiligingsbeoordelingen voor zelfgehoste apps zou markeren als ik het oversloeg.

NGINX-serverblok, afgekort:

server {
  listen 443 ssl http2;
  server_name notes.example.com;

  ssl_certificate     /etc/letsencrypt/live/notes.example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/notes.example.com/privkey.pem;

  location / {
    proxy_pass http://127.0.0.1:6806;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_read_timeout 3600s;
    proxy_send_timeout 3600s;
  }
}

De Upgrade-headers in WebSocket-stijl zijn belangrijk: SiYuan gebruikt een permanente verbinding tussen de browserclient en de backend. Zonder hen krijg je elke minuut of twee willekeurige toasts met 'verbinding verbroken'.

Nadat de container is geopend, drukt u op https://notes.example.com, voert u uw toegangscode in en u bent binnen. De browserclient biedt de volledige SiYuan-ervaring: dezelfde gebruikersinterface als de desktop-app, dezelfde ondersteuning voor plug-ins, dezelfde query-engine. Het enige dat ontbreekt zijn de integraties op besturingssysteemniveau, zoals het systeemvak.

Dat is een installatie van 10 minuten als je al een VPS hebt. Vergelijk het met Obsidian, waarbij bij zelfgehoste synchronisatie van meerdere apparaten services van derden, S3-buckets of het betaalde Obsidian Sync-abonnement betrokken zijn. Het feit dat SiYuan van nature zelf-hostbaar is, is een structureel voordeel, geen nice-to-have.

Grafiekweergave — Handig hulpmiddel of eye candy?

De grafiekweergave van Obsidian werd niet voor niets een meme. Het is prachtig. Het is voor de meeste mensen ook een screensaver. Je staart naar de constellatie van je aantekeningen, voelt je even onder de indruk van je eigen schijnbare diepgang en sluit dan het tabblad.

SiYuan heeft een eigen grafiekweergave en ik wil je vertellen dat dit anders is. Meestal niet.

Dezelfde knooppunt-en-randvisualisatie. Dezelfde natuurkundige simulatie waarmee je clusters kunt slepen. Dezelfde kleurcodering per tag of documenttype. De interactiviteit is prima. U kunt op een knooppunt klikken en naar het document springen. U kunt filteren op tag, diepte, documenttype of tijdsbereik.

Wat SiYuan wel toevoegt, zijn grafiekknooppunten op blokniveau. De grafiek van Obsidian behandelt bestanden als knooppunten. SiYuan kan individuele blokken als knooppunten weergeven, wat betekent dat de grafiek de daadwerkelijke referentiestructuur weerspiegelt: een blok in document A waarnaar wordt verwezen door een blok in document B wordt weergegeven als een rand tussen blokken, niet tussen bestanden.

Is dat echt nuttig? Twee keer in drie maanden, ja. Een keer toen ik op zoek was naar verweesde blokken (blokken die ik had geschreven maar waar ik nooit naar had verwezen) en een keer toen ik naging hoe een specifieke architectonische beslissing zich had verspreid over meerdere ADR's. Beide keren liet de grafiek op blokniveau me iets zien dat een grafiek op bestandsniveau verborgen zou hebben gehouden.

De overige 90% van de tijd is de grafiekweergave gesloten. Ik denk niet dat dit een SiYuan-specifieke fout is. Ik denk dat grafiekweergaven in het algemeen worden oververkocht als kennisinstrument. Ze zijn nuttig voor incidentele structurele inspecties, niet voor dagelijks werk.

Als u alleen op basis van de kwaliteit van de grafiekweergave tussen SiYuan en Obsidian kiest, doe dat dan niet. Ze zijn gelijkwaardig. De optie op blokniveau in SiYuan is een marginale overwinning voor een klein aantal gebruiksscenario's.

Realiteitscontrole van bestandsformaat — .sy JSON, niet Markdown

Dit is waar SiYuan om de grootste inzet vraagt, en waar de meeste recensies voorbij de kosten gaan.

Obsidian slaat notities op als .md-bestanden. Effen Markdown. Je kunt ze openen in Vim, in VS Code, in Kladblok, in elke editor die de afgelopen 30 jaar heeft bestaan. Als Obsidian morgen verdwijnt, zijn uw aantekeningen nog steeds voor altijd leesbaar.

SiYuan slaat Markdown niet op. Het slaat .sy-bestanden op, dit zijn JSON-documenten die de abstracte syntaxisboom (AST) van elke notitie bevatten. Bestandsnamen bestaan ​​uit 14-cijferige tijdstempels plus 7 willekeurige tekens, zoiets als 20260418142733-x7k9j2m.sy. De mapstructuur weerspiegelt uw notitieblokhiërarchie. De inhoud bevindt zich in de JSON, tijdens runtime geïndexeerd door SQLite.

Dit is de afweging die u betaalt voor stabiele blok-ID's. De blok-ID is de AST-knooppunt-ID. De AST moet in een gestructureerd formaat worden bewaard om de ID's tijdens bewerkingen stabiel te houden. Markdown heeft van nature geen identiteit op blokniveau. Er is geen manier om een ​​ID aan een alinea te verankeren die voldoet aan de specificaties in CommonMark. Als je de block-ID-garanties wilt, kun je niet gewoon Markdown als opslagformaat gebruiken. Kies er een.

Wat dit feitelijk betekent voor de draagbaarheid:

U kunt exporteren naar Markdown. SiYuan heeft een ingebouwde Markdown-export: één document, map of hele werkruimte. De export is goed. Blokreferenties worden standaard referenties in wikilink-stijl, codeblokken overleven, tabellen worden netjes geconverteerd. Je wordt niet opgesloten.

U kunt de opslag niet rechtstreeks bewerken. Als u uw notities bulksgewijs wilt wijzigen met een sed-script, zoals u dat zou doen met een Obsidian-kluis, gaat u JSON AST-knooppunten parseren, en geen regex-matching Markdown. Dat is te doen (het AST-schema is gedocumenteerd), maar het is een orde van grootte meer werk dan een oneliner tegen .md-bestanden.

Externe tooling-integratie is moeilijker. Tools zoals Pandoc, Marksman, markdownlint of een van de tientallen CLI-hulpprogramma's die werken op Markdown-bestanden werken niet rechtstreeks op .sy JSON. U kunt exporteren, de tool uitvoeren en opnieuw importeren, maar dat is een workflow en geen reflex.

Synchronisatieconflicten zien er anders uit. Als u een werkruimte synchroniseert via Syncthing of rsync tussen twee machines, zijn conflicten in .sy JSON-bestanden moeilijker handmatig op te lossen dan conflicten in gewone Markdown. De officiële synchronisatie van SiYuan (een betaalde lidmaatschapsfunctie) regelt dit met end-to-end gecodeerde incrementele synchronisatie, maar als je je eigen synchronisatie uitvoert, zul je dit voelen.

Voor mij is de afweging de moeite waard. Mijn aantekeningen zijn nu infrastructuur, geen literatuur. Ik wil dat ze opvraagbaar, referentiestabiel en structureel expliciet zijn. JSON-AST-opslag is de prijs van die eigendommen, en de Markdown-export geeft me een brandontsnapping als ik ooit van gedachten verander. Maar als uw aantekeningen voornamelijk uit proza ​​bestaan ​​(tijdschriften, fictie, dagelijkse reflecties) en de aantrekkingskracht van .md de bewerkbaarheid in elk hulpmiddel is, is SiYuan de verkeerde keuze en moet u bij Obsidian blijven. Dat is geen fout. Het is een ontwerpbelasting voor een ander doel.

SiYuan versus Obsidian versus Notion — Eerlijke vergelijking

Elk "X vs Y"-artikel verandert uiteindelijk in een functiematrix. Hier is de mijne, met de opmerking dat de rijen die er het meest toe doen, de rijen zijn waar de drie tools het echt niet eens zijn.

winkelcentrum, voornamelijk Chinees | Groot, eerst Engels | Geen — gesloten platform | | Realtime samenwerking | Beperkt | Beperkt | Uitstekend | | Offline eerst | Volledig | Volledig | Gedeeltelijk (alleen cache) | | Leercurve | In het begin steil | Matig | Ondiep | | Mobiele apps | iOS, Android, HarmonyOS | iOS, Android | iOS, Android | | Kosten | Gratis (betaalde synchronisatie optioneel) | Gratis (betaalde synchronisatie optioneel) | Gratis → betaalde niveaus |

Mijn mening, rij voor rij, over de rijen die er echt toe doen:

Referentiestabiliteit. SiYuan wint regelrecht. Dit is de functie die mij aantrok en degene die ik nog steeds waardeer. Als u aantekeningen regelmatig reconstrueert, is dit belangrijker dan wat dan ook.

Native query. SiYuan wint opnieuw, met een marge. SQL > Dataview DSL > Filter-UI van Notion. Het feit dat de query-engine deel uitmaakt van het kernproduct en niet van een plug-in, maakt een echt verschil voor productiekritische documenten.

Portabiliteit van bestandsformaten. Obsidian wint, punt. Gewoon Markdown is het meest draagbare notitieformaat dat ooit is uitgevonden. Je geeft dit op om de blok-ID's te krijgen.

Plugin-ecosysteem. Obsidian wint met een mijl. De marktplaats van SiYuan bestaat, de community-bazaar-repository wordt elk uur automatisch bijgewerkt en er is sprake van actieve ontwikkeling, maar het ecosysteem is kleiner en neigt meer naar Chineestalige plug-ins. De selectie van Engelse plug-ins is schaars en de Engelse documentatie voor de ontwikkeling van plug-ins wordt openlijk erkend als een gebied dat werk behoeft. Als je leeft en sterft met community-plug-ins, is dit van belang.

Realtime samenwerking. Notion wint. Niets in de local-first-ruimte komt in de buurt van Notion's "tien mensen die tegelijkertijd dezelfde pagina bewerken" -ervaring. Als uw aantekeningen een teamartefact zijn, is Notion het antwoord en is SiYuan versus Obsidian helemaal het verkeerde frame.

Zelfhosting en eigendom. SiYuan wint. Obsidian is eerst lokaal, maar de officiële synchronisatie is een betaalde SaaS. Notion is pure cloud. SiYuan met Docker biedt u de lokale voordelen plus het gemak voor meerdere apparaten zonder afhankelijk te zijn van de servers van iemand anders die online blijven.

De kop SiYuan vs Obsidian-vergelijking resulteert in: SiYuan als uw aantekeningen gestructureerde documentatie zijn; Obsidian als uw aantekeningen proza ​​plus plug-ins zijn. De Notion vs SiYuan-vergelijking is nog eenvoudiger: Notion als u realtime teamsamenwerking nodig heeft; SiYuan als u privacy, eigendom en een query-engine nodig heeft die u beheert.

Waar SiYuan verliest

Tot nu toe ben ik genereus geweest. Hier zijn de ruwe randen die ik tegenkwam, in volgorde van prioriteit.

Het plug-in-ecosysteem is klein en moeilijk te navigeren in het Engels. De ontwikkelaarsgemeenschap van SiYuan is grotendeels Chineessprekend, wat geweldig is voor de diepgang en consistentie van het project, maar minder goed voor gebruikers die alleen Engels spreken. De gebruikersinterface van de marktplaats is tweetalig, maar bij beschrijvingen en documentatie van plug-ins wordt het Chinees vaak eerst scheefgetrokken. Er is een open GitHub-probleem (#12878) expliciet over het verbeteren van de Engelse ondersteuning. Als uw idee van een perfecte notitietool handgekozen community-plug-ins voor elke micro-workflow omvat, zal SiYuan u frustreren.

De gebruikersinterface voelt voor sommige gebruikers gedateerd aan. Dit is subjectief en ik probeer eerlijk te zijn. De ontwerptaal van SiYuan ligt dichter bij een veelzijdige IDE uit 2018 dan bij een minimalistische app uit 2026. Er zijn veel knoppen. De pictogrammenset is bezet. Het standaardthema is prima, maar niet mooi. Als je uit de zuivere Plain CSS-esthetiek van Obsidian of het luchtige ontwerp van Notion komt, zal het eerste uur in SiYuan rommelig aanvoelen. Na een week merk je het niet meer, maar de eerste indruk doet ertoe.

De prestaties nemen af ​​op grote werkruimten. Het SQLite-geïndexeerde model is snel, totdat dit niet meer het geval is. Mijn hoofdwerkruimte bestaat uit ongeveer 1.800 documenten met in totaal misschien 40.000 blokken, en SiYuan handelt dit zonder klachten af. Mensen die hebben gemeld dat ze meer dan 10.000 documentwerkruimten gebruiken, beschrijven een merkbare vertraging bij het zoeken in volledige tekst en het weergeven van grafieken. Er is een actieve technische draad over het optimaliseren hiervan, maar als uw bestaande Obsidian-kluis echt enorm is, valideer dan de prestaties voordat u zich vastlegt.

De migratiekosten van Notion zijn reëel. De export van Notion is HTML of Markdown met een mapstructuur die niet goed aansluit bij het notebookconcept van SiYuan. U kunt de meeste inhoud binnenhalen, maar u verliest Notion-specifieke zaken: relationele databasekoppelingen, pagina-eigenschappen, insluitingen en eventuele bloktypen die alleen voor Notion gelden. Plan een weekend, geen middag.

Mobiele ervaring is functioneel, niet verrukkelijk. De Android- en iOS-apps werken. Ze synchroniseren. Ze geven correct weer. Maar de editor op mobiel is een duidelijke tweederangsburger vergeleken met de desktop. Blokmanipulatie op een telefoon is lastig, en complexe blokken (SQL-insluitingen, grafieken, wiskunde) worden vaak weergegeven, maar kunnen niet goed worden bewerkt. Als je notities eerst mobiel wilt vastleggen, is dit een echte beperking.

Functies op lidmaatschapsniveau voor geavanceerde synchronisatie. End-to-end gecodeerde synchronisatie is een betaalde SiYuan-lidmaatschapsfunctie. De gratis laag is volledig functioneel: u kunt zelf hosten met Docker, synchroniseren via Syncthing of een andere tool en niets materiaal verliezen. Maar de meest gepolijste synchronisatie-ervaring bevindt zich achter een betaalmuur. Dat is eerlijk en de ontwikkelaars verdienen het om betaald te worden, maar het is de moeite waard om te weten voordat je ervan uitgaat dat de gratis ervaring overeenkomt met de marketingscreenshots.

Geen van deze zaken is voor mij een dealbreaker. Samen zijn zij de reden dat SiYuan vs Obsidian geen universele winnaar heeft.

Wie moet overstappen, wie niet

Vergeet generiek advies. Hier zijn betonprofielen.

Schakel over naar SiYuan als u:

• Een ontwikkelaar die een persoonlijk documentatiesysteem onderhoudt (buglogs, runbooks, ADR's, post-mortems van incidenten) waarbij referentiestabiliteit tussen refactoren belangrijker is dan de flexibiliteit van de editor
• Iedereen die een blokreferentie naar een Obsidian-hernoeming kwijt is en wil dat dit niet meer gebeurt
• Een zelfhoster die gestructureerde documenten in Notion-stijl wil, maar weigert bedrijfseigen gegevens op de servers van iemand anders te plaatsen
• Iemand die een kennisbank bouwt die AI-agenten zullen bevragen - de SQLite-index plus HTTP API plus stabiele blok-ID's maken de integratie van agenten echt handelbaar
• Een intensieve gebruiker van relationeel denken die momenteel tegen Dataview vecht en wenst dat de querylaag een echte database is

Blijf bij Obsidian als u:

• Een dagbladschrijver of essayist wiens aantekeningen voornamelijk uit proza bestaan
• Diep geïnvesteerd in het Obsidian plug-in-ecosysteem (Excalidraw, Obsidian Tasks, Smart Connections, Templater) - geen van deze heeft directe SiYuan-equivalenten
• Iemand die .md-portabiliteit tussen tools nodig heeft (Pandoc, statische sitegeneratoren, externe editors)
• Een sologebruiker waarbij het probleem met de gekraakte link het niet waard is om van tool te wisselen

Blijf bij Notion als u:

• Werken aan gedeelde documenten met een team dat realtime multiplayerbewerking nodig heeft
• Een niet-technische gebruiker die waarde hecht aan de Notion-ontwerptaal en het sjabloon-ecosysteem
• Een wiki bouwen voor een bedrijf waarvan het eigendom "het bedrijf" is, en niet "ik persoonlijk"

Voer beide uit als je:

• Een ontwikkelaar met een sterke bestaande Obsidian-kluis, maar een groeiend probleem met gestructureerde documenten. Dit is wat ik doe. Obsidian voor snelle opname en proza; SiYuan voor de gestructureerde documentatielaag; de twee werken samen via Markdown-export wanneer ik dingen tussen hen moet verplaatsen.

De fout die we moeten vermijden, is dit als een of-of-kwestie te beschouwen. De kosten voor het gebruik van twee tools zijn reëel maar klein. De kosten voor het forceren van aantekeningen in prozastijl in SiYuan of gestructureerde documenten in Obsidian zijn veel hoger.

Mijn huidige configuratie: wat ik heb behouden, wat ik heb gemigreerd

Drie maanden na de eerste installatie van SiYuan is hier de feitelijke taakverdeling op mijn systeem.

Bleef in Obsidian: dagelijkse aantekeningen, dagboekaantekeningen, vluchtige opnames, alles wat ik schrijf om na te denken in plaats van om te documenteren. Ongeveer 1.200 bestanden. Het plugin-ecosysteem (met name Templater, Dataview-for-prose en de Local Images Plus-plug-in uit mijn Karpathy-stijl RAG-installatie) is te waardevol om op te geven. Ik bouw nog steeds mijn tweede brein op Obsidian, dat ik heb besproken in mijn diepe duik over Obsidian en Claude Code voor de proza-en-denklaag.

Gemigreerd naar SiYuan: buglogboeken (312 bestanden), runbooks (84 bestanden), ADR's (47 bestanden), documenten over klantbetrokkenheid (ongeveer 200 bestanden) en projectdocumentatie voor actieve opdrachten (variabel). Ongeveer 700 documenten en het groeit. Alles waarbij referentiestabiliteit en SQL-querymogelijkheden belangrijker zijn dan Markdown-portabiliteit.

De integratielaag: een klein Node.js-script dat elke nacht wordt uitgevoerd, de SiYuan-werkruimte exporteert naar Markdown via de API, en de export neerzet in een map Obsidian-indexen. Alleen-lezen, maar het betekent dat mijn op Obsidian gebaseerde zoekopdracht inhoud van de SiYuan-kant kan vinden. De omgekeerde richting (Obsidian → SiYuan) heb ik niet gebouwd omdat ik het niet nodig heb — Obsidian-inhoud verwijst niet naar SiYuan-inhoud; de afhankelijkheid gaat één kant op.

De agentlaag: Claude Code voert rechtstreeks query's uit op mijn SiYuan SQLite-database wanneer ik kennisgrafiekwerk doe. Ik heb het algemene patroon van RAG in Karpathy-stijl over markdown-kluizen behandeld - SiYuan is een rijker substraat voor hetzelfde idee omdat het schema gestructureerd is. In plaats van een prijsverlaging uit te voeren, voert de agent SQL uit: "Geef mij elk bugblok met de tag sev1 van de afgelopen 30 dagen waarbij de hoofdoorzaak Redis vermeldt." Die zoekopdracht duurt 40 ms en retourneert exacte blokken, geen brokken. Voor workflows in het tweede brein van de ontwikkelaar waarbij de agent een gestructureerde context nodig heeft, is dit een zinvolle upgrade.

Waar ik SiYuan NIET voor gebruik: het schrijven van deze blogpost. Het bericht dat je leest is opgesteld in Obsidian, bewerkt in VS Code en opgeslagen als Markdown. Het platte-tekst-overal-model wint nog steeds voor inhoud die op het publieke web terechtkomt. SiYuan is voor documenten die privé blijven en profiteren van structuur.

Dat is het hele plaatje. Twee tools, één workflow, duidelijke lijnen over wat waar leeft.

Het vonnis

SiYuan is niet de nieuwe Obsidian. SiYuan is niet de nieuwe Notion. Iedereen die het zo formuleert, mist wat er eigenlijk interessant is aan de tool.

SiYuan is wat er gebeurt als je ‘identiteit op blokniveau’ serieus neemt als een primitief en er een kennissysteem omheen bouwt. Het blok-ID overleeft zetten. De SQL-engine indexeert de blokken. De grafiekweergave geeft ze weer. De HTTP API stelt ze bloot. Elk kenmerk vloeit voort uit dezelfde architecturale toewijding: blokken zijn reëel, bestanden zijn afgeleid, paden zijn veranderlijk.

Die toewijding maakt SiYuan goed voor gestructureerde documentatie. Het is ook wat het bestandsformaat ondoorzichtig maakt, de migratiekosten reëel maakt en het ecosysteem smaller maakt dan dat van Obsidian. Technische afwegingen zijn zo: kies het onroerend goed dat u het liefst wilt, accepteer de kosten die daarmee gepaard gaan.

Voor de ontwikkelaar die tijdens een refactor een blokreferentie te veel heeft gekraakt en wil dat het probleem niet meer bestaat, is SiYuan het weekend dat nodig is om op te zetten waard. Voor alle anderen is het antwoord genuanceerder, en ik heb geprobeerd de lijnen hierboven eerlijk te trekken.

Weet je nog het runbook waarin ik de link kwijtraakte, helemaal aan het begin? Ik heb het tijdens een weekend in februari opnieuw opgebouwd in SiYuan. Zes weken later heb ik voor de tweede keer mijn volledige bug-logs/-structuur opnieuw ingericht: deze opgesplitst per klant, vervolgens per service, en vervolgens twee jaar aan opgeloste incidenten gearchiveerd. Honderden bestanden verplaatst. Duizenden blokken gereorganiseerd.

Ik heb vanochtend op de link in het runbook geklikt. Het werkte. Zes weken van structurele veranderingen, tientallen zetten, en de referentie wees nog steeds precies waar het moest.

Dat is de hele pitch in één zin: in SiYuan werkt de link nog steeds. Of die ene eigenschap de moeite waard is om van tool te wisselen, hangt af van hoe vaak je hem hebt zien falen in de tools die je nu gebruikt.

Veelgestelde vragen

Is SiYuan echt open source?

Ja. SiYuan heeft een licentie onder AGPLv3 en de bron bevindt zich op GitHub op siyuan-note/siyuan. U kunt zonder beperkingen zelf hosten, forken of bijdragen. Het betaalde niveau (lidmaatschap) omvat de officiële cloudsynchronisatieservice, end-to-end-coderingssleutels en door AI ondersteunde functies, maar geen daarvan is vereist om het kernproduct te gebruiken.

Kan ik mijn Obsidian-kluis migreren naar SiYuan?

Ja, maar met kanttekeningen. SiYuan kan Markdown-bestanden en mapstructuren importeren, die het grootste deel van een Obsidian-kluis beslaan. Wat u verliest: plug-in-specifieke syntaxis (Dataview-query's, metagegevens van de Tasks-plug-in, Templater-sjablonen), Obsidian-specifieke blokreferentiesyntaxis en eventuele aangepaste CSS. Plan om structureel te importeren en vervolgens eventuele plug-ingestuurde workflows handmatig opnieuw op te bouwen in SiYuan-native primitieven.

Is het .sy-bestandsformaat een risico van leverancierslock-in?

Het is een echte overweging, maar geen harde lock-in. SiYuan biedt ingebouwde Markdown-export op document-, map- en volledige werkruimteniveau. De export is high-fidelity voor standaardinhoud. U verliest .sy-specifieke functies (blok-ID's, ingebedde SQL-query's, aangepaste blokkenmerken) bij het exporteren, maar het proza, de code en de structuur blijven behouden. Het risicoprofiel ligt dichter bij Notion (export beschikbaar, verliesgevend) dan bij een echte propriëtaire lock-in.

Hoe verhoudt SiYuan zich tot Logseq?

Beide zijn lokaal-eerst en blokgericht. Logseq is de eerste schets met ingebouwde dagelijkse journaling; SiYuan is document-first en er zijn outliner-functies beschikbaar. Logseq slaat notities op als .md met een zijspandatabase; SiYuan winkels .sy JSON. Voor pure schetsen en dagelijkse log-workflows wint Logseq. Voor gestructureerde documentatie en SQL-doorzoekbaarheid wint SiYuan.

Werkt SiYuan offline?

Volledig. De desktop-app en de zelf-gehoste Docker-instantie werken volledig offline: elke functie, inclusief SQL-query's, grafiekweergave en referentieresolutie, draait op basis van de lokale SQLite-index. Voor synchronisatie is een netwerkverbinding vereist (met de officiële cloud van SiYuan of met uw eigen synchronisatiedoel), maar het dagelijkse bewerken en browsen is niet online afhankelijk.

Laten we samenwerken

Wilt u AI-systemen bouwen, workflows automatiseren of uw technische infrastructuur schalen? Ik help je graag.

• Fiverr (aangepaste builds en integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (ondernemingsoplossingen): ramlit.com
• ColorPark (ontwerp en branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io