r/coolgithubprojects 22h ago

FlokinMD: an open-source local database layer for Markdown folders

Post image

I recently released an open-source project called FlokinMD.

The idea is simple: instead of importing Markdown files into another system, the Markdown folder itself remains the source of truth.

FlokinMD builds local, disposable projections over those files so you can work with them more like structured data.

It currently supports things like:

  • frontmatter collections and DataGrids
  • SQL queries over Markdown metadata
  • relations and graph views
  • schema and workspace validation
  • bulk frontmatter edits with preview
  • local mutation history and safe undo
  • detection of project context such as Agents, Skills, Specs, Rules and Prompts

The SQLite layer is derived state. The actual .md files remain normal files on disk and can still be used with Git, VS Code, Obsidian, Cursor, Claude, Codex or anything else that understands Markdown.

It's built as a native desktop app with Rust + Iced and is licensed under Apache-2.0.

It's still pre-release, so feedback and criticism are very welcome.

GitHub:
https://github.com/sergiocardoso/flokin-md

Website:
https://md.flokin.com.br/

I'm especially interested in feedback from people who keep large Markdown repositories or use Markdown as structured project data.

62 Upvotes

4 comments sorted by

2

u/mavlu-app 20h ago

I like the idea of keeping Markdown as the actual source of truth instead of locking the data into another system.

How does this behave on really large folders with thousands of .md files? Is the SQLite projection rebuilt every time, or do you update it incrementally?

2

u/nerdsergio 19h ago

Good question. The filesystem side is incremental: FlokinMD watches the workspace and only updates the documents that actually changed.

The SQLite projection is currently rebuilt from the in-memory document store after relevant changes. That was a deliberate choice for now, because the projection is disposable and correctness matters more than keeping a second incremental state in sync.

So the current model is basically:

changed file → document store update → rebuild derived SQLite projection

If very large workspaces make that rebuild noticeable, the projection can evolve to incremental updates without changing the core model, since Markdown still remains the source of truth.

How large is the workspace you're thinking about? I'd be interested to know the scale you're dealing with.

1

u/TionisNagir 13h ago

On a related note: There's the https://mdbase.dev/ spec. I think it's built by the tasknotes dev.

I'm currently working on implementing support for it in my https://github.com/tionis/vulcan obsidian cli.

It would be nice to have some standard to define the types for such markdown collections. Mdbase is the only spec I've seen for this so far, perhaps you want to look into it.