Skip to content

Bases

Bases turns notes and frontmatter into structured views without moving data out of the vault.

A Bases table view in Lapis Notes.

Bases reads file fields, frontmatter properties, and formulas from a base document, then renders those records as table, card, list, or map-oriented views.

Create a .base or .bases file, then configure filters, properties, formulas, and views. Bases can render table and card-style views over matching notes.

  • Project lists
  • Reading queues
  • Content inventories
  • Task dashboards
  • Notes grouped by status, owner, folder, tag, or property

Bases reads file fields such as names and paths, explicit frontmatter properties such as note.status, and formulas declared in the base document. Keep property names consistent across notes to make bases reliable.

Bases now asks the app database to narrow candidate rows before the full Bases query runs. Today that database pushdown is limited to a small operator subset:

Bases operator or behaviorPushed into the app databaseNotes
file.inFolder(...)YesFolder-style path prefix filtering.
file.hasTag(...)YesUses indexed tag records.
file.hasProperty(...) and !hasProperty(...)YesUses indexed frontmatter-property presence.
file.ext = ...YesOnly direct extension equality is pushed down.
Property comparisons like note.status = "draft" or priority >= 2YesLimited to scalar =, !=, >, >=, <, and <=.
Sort by file.path, file.ext, file.mtime, file.size, or a direct propertyYeslimit is only pushed down when every active sort fits the supported subset.
OR groups, custom filter strings, formulas, group-by, and view searchNoThese still run in Bases after rows load.
File predicates outside the subset above, or link filters such as file.hasLink(...)NoThese still work, but they are not database-pushed today.

Unsupported operators do not break Bases. They simply stay in the normal Bases query engine after the candidate rows come back from the app database.