❌ A Document Database
✅ A Database for Documents
Schema inference, frontmatter validation, and semantic search for markdown directories. Single binary, no cloud, no setup.
Markdown files can have a YAML block at the top called frontmatter — structured fields that describe the document:
---
title: Rust Tips
tags: [rust, programming]
draft: false
---
# Rust Tips
Your content here...title, tags, and draft are frontmatter fields. Most tools treat these as flat text or ignore them entirely. mdvs sees structure — your directories, your fields, your types. It infers which fields belong in which directories, validates that they're consistent, and lets you search everything with natural language and SQL.
No config to write. No schema to define. Point it at a directory and it figures it out.
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/edochi/mdvs/releases/latest/download/mdvs-installer.sh | shcargo install mdvsgit clone https://github.com/edochi/mdvs.git
cd mdvs
cargo install --path .mdvs treats your markdown directory as a database — and your directory structure as part of the schema.
Consider a simple knowledge base:
notes/
├── blog/
│ ├── rust-tips.md ← title, tags, draft
│ └── half-baked-idea.md ← title, draft
├── team/
│ ├── alice.md ← title, role, email
│ └── bob.md ← title, role
└── meetings/
└── weekly.md ← title, date, attendees
Different directories, different fields. mdvs sees this.
mdvs init notes/mdvs scans every file, extracts frontmatter, and infers which fields belong where:
Initialized 5 files — 7 field(s)
"title" String 5/5 required everywhere
"draft" Boolean 2/5 only in blog/
"tags" String[] 1/5 only in blog/
"role" String 2/5 required in team/
"email" String 1/5 only in team/
"date" String 1/5 only in meetings/
"attendees" String[] 1/5 only in meetings/
draft belongs in blog/. role belongs in team/. The directory structure is the schema.
Two new files appear — both without role:
notes/
├── blog/
│ └── new-post.md ← title, draft (no role)
├── team/
│ └── charlie.md ← title (no role)
└── ...
mdvs check notes/1 violation — "role" MissingRequired in team/charlie.md
charlie.md is missing role — but new-post.md isn't flagged. mdvs knows role belongs in team/, not in blog/.
mdvs search "weekly sync" notes/1 meetings/weekly.md 0.82
2 team/alice.md 0.45
Filter with SQL on frontmatter fields:
mdvs search "rust" notes/ --where "draft = false"No config files to write. No models to download manually. No services to start.
Try it yourself! Clone the repo and explore a richer example — 43 files across 8 directories, with type widening, nullable fields, nested objects, and deliberate edge cases:
git clone https://github.com/edochi/mdvs.git cd mdvs mdvs init example_kb/ mdvs search "experiment" example_kb/
- Schema inference — types (boolean, integer, float, string, arrays, nested objects), path constraints (allowed/required per directory), nullable detection. All automatic.
- Frontmatter validation — wrong types, disallowed fields, missing required fields, null violations. Four independent checks, path-aware.
- Semantic search — instant vector search using lightweight Model2Vec static embeddings. Default model is ~30MB. No GPU, no API keys.
- SQL filtering —
--whereclauses on any frontmatter field, powered by DataFusion. Arrays, nested objects, LIKE, IS NULL — full SQL. - Incremental builds — only changed files are re-embedded. Unchanged files keep their chunks. If nothing changed, the model isn't even loaded.
- Auto pipeline —
searchauto-builds the index.buildauto-updates the schema. One command does everything:mdvs search "query". - JSON output — all commands support
--output jsonfor scripting and CI.
| Command | Description |
|---|---|
init |
Scan files, infer schema, write mdvs.toml |
check |
Validate frontmatter against schema |
update |
Re-scan and update field definitions |
build |
Validate + embed + write search index |
search |
Semantic search with optional SQL filtering |
info |
Show config and index status |
clean |
Delete search index |
Full documentation at edochi.github.io/mdvs.