Get AI summaries of any video or article — Sign up free
HUGE Update for Obsidian: Bases thumbnail

HUGE Update for Obsidian: Bases

5 min read

Based on Obsidian Explained (No Code Required)'s video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

Bases is a new Obsidian core plugin that enables database-style filtering, sorting, and editing using file properties through a graphical interface.

Briefing

Obsidian’s new “Bases” core plugin brings database-style filtering and sorting directly into Obsidian—using properties and a point-and-click interface—so users no longer need community plugins or heavy setup to build workable personal databases. Instead of wrestling with Data View for straightforward queries, Bases lets people create custom “views” that edit, sort, and filter notes based on file properties, turning a vault of Markdown files into something that behaves more like a structured catalog.

The workflow starts with enabling Bases under Core Plugins, then creating a new base. At first, a fresh base shows everything in the vault, which can look like a cluttered list. The value comes from adding properties to files—such as “teacher,” “topic,” and “price”—and then filtering the base using simple logic. Bases supports common query patterns: “all of the following are true” for strict matching, or “any of the following are true” for broader results. With those filters in place, a base can instantly narrow a folder like “courses to take” down to only the notes that match the selected property conditions.

A key usability feature is how Bases handles property visibility and defaults for new records. Users can choose which properties appear as columns in the table view. Once those properties are enabled for the base, new notes created from that view inherit the same property set, reducing repetitive setup. The transcript highlights a common confusion: property visibility isn’t automatically shared across every view. Switching between views (for example, from table to cards) can require re-enabling which properties are shown, and the “top” view becomes the default when returning to the base.

Bases also supports richer layouts through card views. By adding an image property (e.g., “cover image”) and attaching an image to a note, the base can render that image in the card interface. The plugin includes an “image fit” option (such as cover behavior) and lets users adjust aspect ratio handling—useful for different library-style layouts like vertical book lists or wide, cinematic thumbnails.

In practice, Bases is positioned as a way to build complex, multi-view databases—movies to watch vs. movies watched, books in a library vs. loaned books, or course catalogs—without writing code. The approach is to create one “main” view for adding new records and then use secondary views as filtered slices for specific statuses or categories. The result is a structured system built from properties and filters, delivered through a graphical interface rather than query syntax.

Overall, Bases aims to make Obsidian feel less like a plain note vault and more like a customizable database platform—fast to set up, easy to query, and flexible enough to support both table and card-style browsing.

Cornell Notes

Bases is a new Obsidian core plugin that turns notes into database-like records using file properties and clickable filters. Users create a base, add properties (e.g., teacher, topic, price) to notes, then build views that show only matching records using logic like “all of the following are true” or “any of the following are true.” Bases can display data in table form and also render card views with image properties, including cover-image behavior and aspect ratio options. A major usability point is that property visibility and defaults depend on the view configuration, so the main “add new records” view should include the properties users want by default. This enables multi-view systems like “loaned books” vs. “library books” without code or community plugins.

How does Bases turn a vault of notes into a queryable database?

It relies on file properties plus filtered views. After creating a base, the user adds properties to individual notes (for example: teacher = “Jonathan Pritchard,” topic = “business,” price = a number). Then the base’s filter logic selects which records appear—using conditions such as “all of the following are true” (AND-style matching) or “any of the following are true” (OR-style matching).

What’s the practical difference between “all of the following are true” and “any of the following are true” in Bases?

“All of the following are true” narrows results to notes that match every selected property condition simultaneously (e.g., teacher AND topic AND price constraints). “Any of the following are true” broadens results to notes that match at least one selected condition (e.g., teacher OR topic OR another property). This changes how quickly a base becomes a precise slice vs. a broader feed.

Why does property setup sometimes feel inconsistent when switching between table and card views?

Property visibility and enabled columns aren’t automatically carried across every view. The transcript notes that returning to the base can default to the topmost view, and that properties may need to be re-enabled for the view you’re using. A common fix is to treat one view (often the table view) as the “main” add-record view, while secondary views act as filtered displays.

How do image-based card views work in Bases?

Users add an image property (e.g., “cover image”), attach an image to the note, and then configure the card view to render that property. The card view uses the image property’s path to display the image, and it includes options like image fit behavior (e.g., cover) and aspect ratio handling (vertical vs. wide layouts such as 4x3 or 16:9-style proportions).

What’s the recommended strategy for building multi-view databases like “loaned books” vs. “library books”?

Create a main view that includes all properties needed when adding new records, then add secondary views that filter based on a status property (for example, a “loaned” boolean or a “where property is loaned” condition). This keeps data entry simple while making browsing effortless through pre-filtered slices.

Review Questions

  1. When would you choose “all of the following are true” instead of “any of the following are true” for a base filter?
  2. What steps are required to make an image property appear in a card view, and what configuration controls how the image is displayed?
  3. How should you structure your views so that new notes inherit the correct set of properties by default?

Key Points

  1. 1

    Bases is a new Obsidian core plugin that enables database-style filtering, sorting, and editing using file properties through a graphical interface.

  2. 2

    A new base initially shows all vault files, but value comes from adding properties to notes and applying filter logic like AND (“all…true”) and OR (“any…true”).

  3. 3

    Property visibility and defaults depend on view configuration, so the view used for adding records should include the properties users want every time.

  4. 4

    Card views can render images by using an image property (e.g., “cover image”) attached to notes, with options for image fit and aspect ratio behavior.

  5. 5

    The default view when returning to a base is determined by which view sits on top, so arranging views affects what users see first.

  6. 6

    Multi-view setups (e.g., loaned vs. owned items) can be built by using secondary views as filtered slices while keeping one main view optimized for data entry.

Highlights

Bases replaces code-heavy database workflows with property-driven, click-to-filter views built into Obsidian.
Filtering supports both strict matching (“all of the following are true”) and flexible matching (“any of the following are true”).
Card views can display attached images via an image property, with configurable cover behavior and aspect ratio handling.
Property columns and visibility aren’t automatically universal across views—setup is view-specific, and the top view becomes the default when revisiting a base.

Topics