DEV Community

Cover image for LeafWiki Devlog #7: v0.6.1 - Introducing Backlinks + Better Search (SQLite FTS5) 🌿
perber
perber

Posted on • Edited on

LeafWiki Devlog #7: v0.6.1 - Introducing Backlinks + Better Search (SQLite FTS5) 🌿

#opensource #go #markdown #documentation

Hi!

It’s time for another update on LeafWiki 🌿

The new version v0.6.1 focuses on two things you use constantly in a wiki:

  • Search — fuzzy search & improved ranking
  • Backlinks / link UX — introducing backlinks

If you’re new here: LeafWiki is a lightweight, self-hosted Markdown wiki built as a single Go binary.

It’s for people who think in folders, not feeds.

LeafWiki stores everything locally — Markdown files on disk, plus a small tree file for structure and metadata.

If LeafWiki disappears tomorrow, your content is still yours.

👉 GitHub: https://github.com/perber/leafwiki

Backlinks

Backlinks are one of those features that turn a wiki into a knowledge base.

They also enable something important: showing the impact of moves and renames - because in a real wiki, pages don’t stay static forever.

LeafWiki follows an explicit approach here (similar to working in an IDE):
when you rename or move a page, you can decide whether links inside Markdown should be updated as well.

(Automatic link updates are planned for a future release.)

Backlinks answer questions like:

  • “Where is this page referenced?”
  • “Which docs depend on this decision?”
  • “What’s connected to this topic?”

What’s included in v0.6.1 (Backlinks & Links)

  • Incoming backlinks per page
  • Outgoing link list
  • Broken links are tracked (so you can see what needs fixing) (A dashboard / overview for broken links is planned for a future release.)
  • The link section was intentionally made less visually dominant, so your page content stays the focus

My goal is to make link navigation feel useful without turning LeafWiki into a graph tool.

This is the first release where I’m properly introducing backlinks — and I’d love feedback on how you use them.

Search improvements for a Markdown based wiki

Search is a daily driver feature — if search feels unreliable, a wiki slowly turns into a graveyard.

In v0.6.1, I focused on making search feel more reliable and practical during day-to-day use.

🛠️ Under the hood: local SQLite FTS5 (no external services)

LeafWiki is file-based, so search needs to be fast without requiring a separate DB server or Elasticsearch.

LeafWiki uses a local SQLite FTS5 index (search.db) and keeps it up to date.

A few implementation details for devs & self-hosters:

  • Parallel indexing: Markdown files are indexed using a small worker pool
  • Markdown-aware indexing: headings are extracted and indexed separately so important sections rank well
  • Relevance ranking: results are ordered with BM25 weighting (title > headings > content)
  • Better UX: highlighted titles and snippets/excerpts generated directly by FTS
  • Fuzzy-by-default: normal queries get * wildcards automatically

(Optional: tiny schema snippet)

CREATE VIRTUAL TABLE pages USING fts5(
  title,
  headings,
  content,
  tokenize = "unicode61 tokenchars '-_/+#.'"
);
Enter fullscreen mode Exit fullscreen mode

Feedback welcome

Backlinks can be a deep rabbit hole (graphs, tags, multi-references, etc.).

LeafWiki tries to keep it simple — but useful.

So I’d love to hear:

  • Do you use backlinks in your documentation or more for knowledge management?
  • Should the link section be more prominent, or is the subtle approach better?

Thanks for following along 🌿

Try it out: https://demo.leafwiki.com

If you like the project, check it out on GitHub: https://github.com/perber/leafwiki

Top comments (0)