Obsidian Bases: turn reference notes into live views

TL;DR — A Base is a YAML file that points at a folder or tag, treats every matching note’s frontmatter as a row, and renders the result as a sortable, filterable, editable table or card grid [1]. For an intermediate user with messy reference notes, the upgrade path is: (1) add 2-4 consistent properties to the notes you want to query, (2) Bases: Create new base, (3) filter by folder/tag, (4) tick the properties you want as columns, (5) save named views. It shipped in Obsidian 1.9 on May 21, 2025 [3] and is the first-party answer to Dataview ⭐ 9.0k (May 2026) [8] — but it only reads YAML frontmatter, not inline key::value or inline tasks, which is the one rewrite the migration will force [24] [30].

What Bases actually is

A Base is a .base file (YAML) that defines filters over your vault and renders the matching notes as a database-style view [1]. Rows are notes; columns are YAML properties. Editing a cell writes back to that note’s frontmatter, so the view is fully live in both directions [5]. Bases shipped as a core plugin in Obsidian 1.9 (Desktop early access May 21, 2025) [3], was refined in 1.9.2 with file-level properties like file.path, file.links, file.tags and object-oriented chained syntax [4], and gained a List view plus a Bases plugin API in 1.10 [2]. Community framing: “biggest update since Properties” [7].

Bases is the GUI query layer over the Properties feature — every column is a frontmatter key. That means you can’t query notes that have no frontmatter, and the first concrete adoption step for an intermediate user is usually adding 2-4 consistent properties to a folder of existing reference notes.

The five-step conversion workflow

The mechanical click-path to turn a folder of reference notes into a live view:

1. Stamp properties. Open each note, use Cmd/Ctrl+; to add at least one shared property (e.g. type: book, status: read, rating: 4). The fastest mass-edit is Obsidian’s Properties view in the right-hand sidebar — select multiple notes in the file explorer and set a property across all of them at once. Without consistent frontmatter, Bases has nothing to query [24].
2. Create the base. Command palette → Bases: Create new base drops a .base next to the active note; Bases: Insert new base embeds one in the current note; right-click any folder → New base scopes it to that folder [9].
3. Set the global filter. Top-right “Filters” → pick file → has tag (or in folder, or a property comparison). Three idioms cover 90% of cases: file.inFolder("Books"), file.hasTag("book"), type == "book" [13].
4. Pick columns. “Properties” panel → tick the frontmatter keys you want as columns. A pragmatic starter set: file.name, two or three note properties, and a throwaway file.path you delete once the filter is right [14].
5. Save named views. Click the view-name dropdown top-left → “Add view” (or Bases: Add view). Each view stores its own type, filters, ordering, and limit — so “All books”, “To read”, “5★” can coexist as tabs in one base [10].

Anatomy of a .base file

A .base is YAML with five top-level keys [10]:

filters:    # global conditions applied to every view
formulas:   # custom calculated properties
properties: # display config for columns
summaries:  # custom aggregations
views:      # one or more named views (table / cards / list / map)

Filters compose with nested and / or / not blocks combining file functions (file.hasTag(), file.inFolder(), file.hasLink()) and property comparisons [4]. Filters apply in two layers: a global filter selects a subset of the vault, then each view further prunes that subset [6].

Bases ships four built-in view types:

Source: official Views docs [11]. Cards take a cover property (wiki-link, URL, or hex colour) and a fit setting of cover or contain — that’s the “gallery” pattern, there’s no separate gallery view type [12].

You can embed a Base inline with a ```base code fence, or transclude a standalone file with ![[Library.base]] or ![[Library.base#5★]] to pin a specific view [10].

Steal these recipes

Book library

The reference-standard public example is uroybd/Book-Base ⭐ 16 (May 2026) — a full vault with six views (All Books, Queue, Published, Series Cards, By Year, Current Year) [15]:

filters:
  and:
    - file.folder.contains("Personal/Reading/Books")
    - file.ext != "base"
formulas:
  Title: link(file.path, title)
  Rating: if(rating == null, "N/A", ["⭐", rating.toString()].join(" "))
  Cover: image(cover)

For a simpler start, the Practical PKM book-library recipe filters by folder and ships three views: a default table, a primary cards view (cover/author/rating/pages), and a “5 Star Books” cards filtered on rating == 5 [16]. For yearly reading logs, the array-property pattern is readDates.filter(value.toString().contains("2025")) [17].

Project / task tracker

The canonical forum template standardises four keys — status, passion (1-5), deadline (datetime), progress (0-100) — and uses display-formula columns for emoji ratings and progress bars [18]:

status: In Progress
passion: 5
deadline: 2025-08-19T12:51:00
progress: 60

The companion “home base” tutorial filters by file.tags.containsAny("projects","exam") with priority + due-date sort [19].

Meetings + people (inverse-link pattern)

Two bases hang off a Type: Meeting note schema with Attendees and Projects link-list properties. Inside a person’s note, an embedded base filters Type == "Meeting" AND Attendees.contains(this.file); inside a project’s note, swap Attendees for Projects [20]. This is the single most useful Bases trick for intermediate users — it lights up the graph by reading existing links as data.

Media log

Obsidian-TV-Tracker ⭐ 25 (May 2026) defines a ready-to-use movie/TV frontmatter shape — title, type, status (Watchlist / Watched / In Progress / Complete / Incomplete), priority, rating, dates, progress, external link — that drops straight into a Bases source schema with no rework [21].

Recipes

The community recipe-sheet template tags notes #🍽️/recipe and uses a multi-select ingredients property (curated from ~300 common ingredients via Metadata Menu) — directly portable to a Bases ingredients.contains("garlic") filter [23].

Daily-notes “On This Day”

A daily-notes base parses the filename as a date and exposes month/day/year as formula columns, then filters on month == today().month && day == today().day for a flashback view [19].

Base-of-Bases home page

A cards-view index of every other base, using file.basename + ".jpg" as the cover-image formula, makes a visual launcher [22].

The formula layer — what “live” actually means

Every column can be a stored property or a computed formula [10]. The formula language is small and learnable in an afternoon. Operators: arithmetic + - * / % (), comparison == != > < >= <=, boolean ! && ||. Dates accept duration-string arithmetic: date + "1M", date - "2h" [41] [4].

Each note row exposes a file.* object alongside user frontmatter [4]:

Global functions cover if(cond, then, else?), now(), today(), date(), duration(), link(), list(), min/max, number(), image(), icon() [41]. Date values expose .year/.month/.day/.hour, .format() (formatting tokens), .relative() (“3 days ago”); subtracting two dates yields a Duration unwrapped via .days / .hours [4]. Lists chain .filter(), .map(), .reduce(), .contains*, .join(), .unique(), .sort() [4].

Useful starter formulas:

The first three from optional.page [10]; rating/cover from uroybd/Book-Base ⭐ 16 (May 2026) [15]. Live-update gotcha: edits made through Obsidian’s properties UI re-render the open Base immediately, but plugins or external tools that write via app.vault.modify() can leave the metadata index stale until you run Settings → Files and Links → Rebuild Cache [42].

Bases vs Dataview

For users with an existing Dataview ⭐ 9.0k (May 2026) library, the comparison is what actually drives the migration decision:

Hacker News consensus: Bases is “like 90% replacement [for Dataview] and faster”, and Dataview’s maintainer-blessed successor Datacore is stalled [26]. Practical Medium: Dataview is “resting peacefully in a long-term academic sabbatical” [28].

Migration path. Bases-Toolbox ⭐ 52 (May 2026) converts Dataview TABLE queries (fields, aliases, FROM, WHERE, SORT, LIMIT, GROUP BY) into .base files — DataviewJS is explicitly unsupported [25]. Practical PKM’s guide adds that inline key::value data must first be lifted into frontmatter using the Dataview-to-Properties plugin before Bases can see it [24]. Pragmatic rule: rebuild new dashboards in Bases, keep Dataview alive for grouped or task-heavy queries you’d otherwise have to restructure your vault to migrate.

Known limitations and gotchas

The forum and report-card consensus as of mid-2026 — community score 4.4/5, but “still a bit of a work in progress” with a steep learning curve and weak documentation [38]:

Roadmap signal

The official roadmap currently lists Kanban view as “in progress”, and Calendar view + Publish support as “planned” — all three are the most-requested missing pieces from the limitations list above [37]. 1.10’s Bases plugin API already lets community plugins ship custom view layouts (Maps was the proof-of-concept), so expect Gantt / timeline / chart views from the community before Obsidian ships them natively [2].

For an intermediate user, what to do this week

1. Pick one messy folder of reference notes you query mentally (“books I want to read”, “side projects”).
2. Add 2-4 consistent properties to those notes. Use Properties view to mass-edit.
3. Create one base on that folder with a Table view. Spend zero time on formulas.
4. Add a second named view: filtered subset (status / rating / tag).
5. Only after both views feel useful, add one formula column (start with file.mtime.relative() or an Overdue badge).
6. Bookmark or pin the base in your sidebar — it replaces the homepage MOC you were maintaining by hand.

The trap to avoid: building a Base before the underlying notes have consistent frontmatter. The view is downstream of the data, and the data is the work [24].