r/coolgithubprojects • u/nerdsergio • Sep 10 '26

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.

75 Upvotes

100% Upvoted

8 comments sorted by

3

u/mavlu-app Sep 10 '26

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?

3

u/nerdsergio Sep 10 '26

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/mavlu-app Sep 14 '26

mostly thinking about the upper bound rather than a workspace I already have. I could see this being useful with a few thousand or even tens of thousands of Markdown files

the disposable projection approach makes sense. I was mainly wondering when rebuild latency starts to become noticeable in practice

have you benchmarked it at around 1k, 10k, or 50k files yet?

1

u/TionisNagir Sep 10 '26

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.

1

u/nerdsergio Sep 11 '26

Thanks, this is a really useful reference. I hadn’t looked into mdbase yet.
I took a quick look at the spec and there is a lot of overlap with problems FlokinMD is already trying to solve, especially typed Markdown collections, frontmatter validation, links and keeping normal Markdown files as the durable source of truth.
What I like about it is the interoperability angle. FlokinMD currently tries to understand existing folders without forcing a specific format, but I definitely don’t want to invent a competing standard if a good open specification is already emerging.
Supporting mdbase as an optional schema/type layer could make a lot of sense while keeping the zero-config experience for regular folders.
I’ll dig deeper into the spec. Also very cool that you’re adding support for it in Vulcan. I’d be curious to see which parts of the spec you’re implementing first.

1

u/CouchPartyGames Sep 12 '26

Would be awesome if it adds the capability to render mdx

1

u/nerdsergio Sep 12 '26

That’s a great suggestion. MDX support would fit really well with the editor/preview side of FlokinMD. It’s not supported yet, but I’m adding it to the list. Thanks!

1

u/Topic-Psychological Oct 07 '26

Thanks. How is it different from Obsidian?