Get AI summaries of any video or article — Sign up free
Obsidian Bases Just Changed Everything thumbnail

Obsidian Bases Just Changed Everything

5 min read

Based on Linking Your Thinking with Nick Milo's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

Obsidian Bases turns note collections into fast, filterable databases using a new core plug-in.

Briefing

Obsidian Bases introduces a new core plug-in that turns any set of notes into a fast, queryable database—so users can filter, sort, and view thousands of notes instantly without relying on external tooling. The practical payoff is immediate: instead of hunting through a vault or building complex dashboards, people can create “bases” that surface exactly the notes they need (favorite quotes, active projects, recently modified items) with columns and views that behave like a lightweight Airtable-style interface.

The walkthrough starts from scratch. After enabling access (the feature is tied to Obsidian’s versioning and early access via a Catalyst license), creating a base is done through Obsidian’s command palette. Once a base exists, it searches the entire vault rather than being trapped inside a single “database” container—sidestepping a common pain point from other note systems where content can be fragmented across separate databases. From there, the key mechanism is properties plus filters. A user can add a property such as “collection contains quotes,” which links a base to a set of quote notes; applying that filter collapses a massive note collection (10,000+) down to a manageable subset (roughly 70 quotes in the example).

A major focus is replicating the feel of Data View, a popular third-party plug-in used in IdeaVerse Pro. The transcript shows how to build a quotes table with columns like rank and author, then sort by rank so the highest-rated quotes float to the top. Obsidian Bases currently has some rough edges—properties aren’t always obvious in the UI until users type search terms, and formatting/capitalization can be adjusted at the table level without rewriting metadata across every note. Even so, the results are functional and responsive.

Three “best features” anchor the argument for why Bases matters. First is speed: large tables scroll smoothly even with tens of thousands of files, while Data View can become sluggish or freeze during heavy table rendering. Second is multiple views per base: the same base can host different filtered views (e.g., “quotes by rank over four” and “top eight quotes”), and those views can be switched quickly. Third is embeddable views: specific filtered tables can be embedded inside other notes using Obsidian’s linking syntax, letting users drop bespoke database slices into agendas and workflows.

The examples extend beyond quotes. Attempts to recreate a “recently modified” Data View layout highlight current limitations around timestamp formatting and clean folder display. A projects example uses the ACE folder framework (active/simmering/sleeping) to show how Bases can filter by folder path and switch between “all projects” and “active projects,” though the UI may show file paths more messily than desired.

Beyond mechanics, the transcript turns to implications. Bases elevate the importance of Obsidian properties, which can shift thinking from freeform serendipity toward structured, database-like planning. There’s also uncertainty about how AI will interpret bases, since the underlying base format is essentially a compact filtering note rather than a fully rendered dataset. For non-coders, advanced filtering via formulas and functions may be hard today, but community examples and AI-assisted coding could reduce that barrier.

Overall guidance is cautious optimism: Bases is early, promising, and likely to iterate quickly. The recommended approach is to try one or two bases and rebuild useful existing Data View setups—using speed and embeddable views now, while watching for improvements like better property discovery, note counts, and richer formatting.

Cornell Notes

Obsidian Bases adds a core plug-in that turns sets of notes into fast, filterable databases across an entire vault. By using properties (like “collection contains quotes”) and filters, users can narrow thousands of notes down to a targeted subset, then sort and display them in table-like views with columns such as rank and author. The standout advantages are speed on large vaults, multiple views per base (e.g., “rank over four” vs “top eight”), and the ability to embed specific views inside other notes. The tradeoff is that Bases increases reliance on structured metadata (properties) and may nudge workflows away from freeform linking toward more database-style planning. Limitations remain—especially around UI polish, note counts, and advanced formula-driven customization for non-coders.

How does Obsidian Bases avoid the “fragmented database” problem common in other systems?

Bases search the whole Obsidian vault. Unlike setups where content must be placed inside a specific database container to appear in results, Bases treats the vault as one large searchable dataset. That means a base can be created anywhere, and filters still pull matching notes from across the vault rather than requiring notes to live in a particular sub-database.

What role do properties play in building a base like the “quotes” example?

Properties act as the metadata that filters depend on. In the quotes walkthrough, a property such as “collection contains quotes” links a base to a note (or notes) representing the quote set. Once that property is present on the relevant notes, the base can filter to show only those linked quote notes, reducing a large alphabetized list down to a focused table.

Why is the “speed” claim central, and how is it contrasted with Data View?

Speed determines whether database-style browsing is usable. The transcript contrasts Bases’ smooth scrolling on very large tables (tens of thousands of files) with Data View’s tendency to slow down or even freeze the app while loading large tables. The claim is backed by Obsidian leadership mentioning optimizations for scrolling large tables.

How do multiple views and embeddings change day-to-day workflow?

Multiple views let one base host several filtered slices—such as “quotes by rank over four” and “top eight quotes”—switching quickly without rebuilding the base. Embeddable views then allow those slices to be inserted into other notes (like an agenda) using Obsidian’s header-link syntax. The result is “bespoke content” embedded directly where planning happens, rather than forcing users to navigate to a separate dashboard.

What limitations show up when trying to recreate Data View aesthetics (like “recently modified”)?

Some layouts don’t translate cleanly yet. The transcript notes clunky timestamp display (hour/minute/second detail when only the date is desired) and less polished folder-path presentation compared with IdeaVerse Pro’s Data View output. It also hints that formulas/functions could eventually help, but current flexibility is limited.

What are the biggest workflow implications of adopting Bases?

Bases elevate the importance of properties, which can shift thinking from freeform serendipity and spontaneous linking toward structured, architect-style planning and analysis. The transcript frames this as a potential tradeoff: better retrieval and prioritization, but a risk of trading away the joy of wandering and making unexpected connections. There’s also uncertainty about AI compatibility because the base format is essentially a filtering note, not necessarily something AI can interpret as a fully rendered dataset.

Review Questions

  1. When building a base, what specific combination of properties and filters makes the “quotes” subset appear, and how does that reduce the note list size?
  2. What three advantages of Bases are emphasized, and which one most directly affects whether large-table browsing remains practical?
  3. How might embedding a filtered view inside an agenda note change how someone uses their vault compared with opening a separate database view?

Key Points

  1. 1

    Obsidian Bases turns note collections into fast, filterable databases using a new core plug-in.

  2. 2

    Bases search the entire vault, avoiding fragmentation issues where content must live inside a specific database container.

  3. 3

    Properties are the backbone of Bases: filters rely on metadata like linked collections to select the right notes.

  4. 4

    Bases’ standout strengths are speed on large vaults, multiple views per base, and embeddable views that can be inserted into other notes.

  5. 5

    Current UI and formatting rough edges include less intuitive property discovery, missing note counts, and limited control over how some fields (like timestamps) render.

  6. 6

    Adopting Bases can shift workflows toward structured, metadata-heavy thinking, potentially reducing freeform serendipity unless balanced with traditional note practices.

  7. 7

    Advanced customization via formulas/functions is powerful but harder for non-coders today; community examples and AI-assisted workflows may close the gap.

Highlights

Bases can scroll and filter through very large note sets quickly, contrasting with Data View’s tendency to slow down or freeze on big tables.
One base can host multiple filtered views (e.g., “rank over four” vs “top eight”), and those views can be embedded directly into other notes.
Because Bases searches the whole vault, it sidesteps the “wrong database/page” problem that fragments knowledge across containers.

Topics

  • Obsidian Bases
  • Properties and Filters
  • Embeddable Views
  • Data View Comparison
  • Knowledge Workflow Implications

Mentioned