Skip to main content
The LanceDB resource exposes a LanceDB table as a virtual filesystem mounted at some prefix such as /fashion/. Group-by columns become nested folders, each row becomes a card plus an optional blob file, and semantic search is the search command, which returns ranked rows as canonical file paths. For connection setup (LanceDB OSS, object storage, Cloud, Enterprise), see LanceDB Setup.

Config

The mapping is config-driven; nothing about the dataset is hardcoded. Point group_by at different columns and the folder tree changes. See the full config reference.

Filesystem layout

Every path is translated into a LanceDB query. Descending a folder adds one WHERE clause; the leaf level lists rows.
When table is set the table level is elided, so the mount root is that table:

Row cards

A <id>.md card renders the row’s columns as readable text and points at its blob. The vector and blob columns are omitted from the card body.
Search is a command, not a path. It returns each ranked row as its canonical file path (the same <id>.md you would cat while browsing) annotated with the vector distance, followed by the card body. Results point back at the real files, so search composes with cat, pipes, and wc:
Flags: --top-k <n> (default search_limit), --threshold <max-distance>, --method semantic (the only supported method; grep/rg stay lexical).

Supported commands

All commands delegate to Mirage’s shared implementations. grep/rg stay lexical (literal/regex). search is the semantic path: it auto-embeds the query via the table’s embedding function and returns ranked rows as canonical file paths, which compose with cat, wc, and pipes.

Access pattern

The mount is read-only (MountMode.READ); writes are not supported. The two read modes are:
  • Browse by label folders: pure metadata WHERE filters, no embedding.
  • Search by meaning: search "<query>" <path> runs vector search using the table’s embedding function and returns canonical row paths.
Folder listings scan one column with SELECT DISTINCT and are capped by max_rows, so very large tables should keep group_by to low-cardinality columns.