@dSebastien: I run live dashboards over 20,000 notes in Obsidian. No spreadsheets, no manual updates. I change one property on a not…

X AI KOLs Timeline Tools

Summary

A blog post demonstrating how to use Obsidian Bases to create live, self-updating dashboards from over 20,000 notes by treating the vault as a database and leveraging consistent metadata.

I run live dashboards over 20,000 notes in Obsidian. No spreadsheets, no manual updates. I change one property on a note and every dashboard updates itself. Your vault is already a database. Bases are how you finally query it. https://t.co/10tOrz9nvd
Original Article
View Cached Full Text

Cached at: 06/26/26, 10:17 PM

I run live dashboards over 20,000 notes in Obsidian. No spreadsheets, no manual updates. I change one property on a note and every dashboard updates itself. Your vault is already a database. Bases are how you finally query it.

https://t.co/10tOrz9nvd


How I Turned 20,000 Notes Into Live Dashboards With Obsidian Bases

Source: https://www.dsebastien.net/how-i-turned-20-000-notes-into-live-dashboards-with-obsidian-bases/ BlogA Base isn’t a spreadsheet you fill in. It’s a lens you point at notes you already have, and it’s only as sharp as the properties underneath. Here’s how I run live dashboards over 20,000 notes.

Sebastien Dubois

24 Jun 2026—22 min read

How I Turned 20,000 Notes Into Live Dashboards With Obsidian BasesIn this article, I want to show you whatObsidian Basesare, how to build your first one in two minutes, and how I use them to run live dashboards across a vault of more than 20,000 notes. I’ll share real use cases from my own setup: my reading library, my life/health tracking system, the custom Base views I built as Obsidian plugins, and an “AI Base” that indexes the AI agents living inside my vault.

An Obsidian Base showing notes as a Cards view with cover imagesAn Obsidian Base showing notes as a Cards view with cover images## TL;DR

  • **Your vault is already a database.**Every property you’ve ever typed into a note is data. Bases are how you finally query it, with no spreadsheets to keep up to date.
  • **Less filing, more asking.**A Base is a saved question (“what am I reading right now?”, “which days did I sleep badly?”) that answers itself and stays current forever. You change a property; the dashboard updates on its own.
  • **One question, a dozen views.**The same Base becomes a table, a card gallery, a bookshelf, or a graph. Build the query once, look at it however the moment needs.
  • **Clean properties are the whole game.**Bases reward consistent metadata and expose sloppy metadata. Get this right and everything else follows. Get it wrong and no view will save you.
  • **Formulas turn lists into dashboards.**Compute a wellness score, a reading streak, a “this week / this month” bucket. Columns that live in no note but appear on demand.
  • **Faster and friendlier than Dataview.**Native, editable in place, quick even at 20,000 notes. I’ve moved most of my dashboards over.
  • **It goes far past tables.**Plugins can add whole new view types (I built three: charts, periodic reviews, and a knowledge graph), the Obsidian CLI can query Bases from your terminal, ...
  • **You can have AI build and improve them for you.**Describe the dashboard you want in plain English and let the AI write the Base.

What an Obsidian Base actually is

Obsidian Basesis a coreObsidianplugin (no installation needed) that turns any set of notes into a database you can filter, sort, and view in different ways. Think of it as a saved question you ask your vault. “Show me every book I’m currently reading.” “Show me my daily notes from this week with their sleep scores.” “Show me every AI skill I’ve written, grouped by category.”

The key part: you don’t fill a Base with data. The data already lives in your notes, in their properties (also called frontmatter or metadata). A Base just reads it.

It’s a bit like databases inNotion, except a gazillion times faster, and your data stays as plain Markdown files you fully own (cfrFile over app principle).

Each Obsidian Base does three things:

  1. Filtersdecide which notes are included (for example, “has the tagbook”).
  2. Viewsdecide how those notes are displayed (table, cards, and more).
  3. Properties and formulasdecide which columns show up, and what they’re called.

That’s the whole model.

Your first Base in two minutes

Let’s build one. Say you want a list of every book in your vault.

First, a quick setup check. Bases ships with Obsidian, but it’s a core plugin, so it might not be turned on yet. OpenSettings → Core pluginsand make sureBasesis enabled. While you’re there, enable thePropertiescore plugin too. It gives you a clean editor for the frontmatter your Bases will read, and trust me, you’ll want it.

  1. Create the Base. Right-click in the file explorer and chooseNew base, or run theBases: Create new basecommand from the command palette. You get a\.basefile.
  2. Add a filter. By default, Bases include all the notes in your vault. Use filters to select/exclude notes in the Base. UseFile → has tagand pick your book tag. Now the Base shows only your book notes.
  3. Pick your columns. Open the Properties menu and tick the properties you want to see: author, status, rating, pages, reading status, ...
  4. Sort it. Sort by rating descending, or by date finished.

That’s a working database over notes you already had. No data entry. You just pointed a lens at existing notes.

A few things worth knowing early:

  • You can create a Base from the ribbon, the command palette, or by right-clicking a folder.
  • Bases: Insert new basedrops a Base directly into the note you’re editing.
  • Click the result count next to the view name to limit results, copy them, or export to CSV.
  • Click the</\>button next to a filter to reveal the raw syntax. That’s where formulas and advanced filters live, and where we’re heading.

The mental model: one Base, many views

A common beginner instinct is to create a new Base for every situation. Books to read here, books being read there, books finished somewhere else. Three Bases, three files, three things to maintain.

Don’t. CreateoneBase for books, then addmany viewsto it.

Each view in a Base has its own layout, its own sort, its own filters, and its own columns, but they all draw from the same underlying “root” query. My Books Base has a Bookshelf view, a “Currently Reading” table, a cards gallery, a “Read This Year” table with totals, and separate fiction and non-fiction galleries. One file. Six views.

One Books Base, shown as a Cards view with cover images pulled from a propertyOne Books Base, shown as a Cards view with cover images pulled from a propertyThe same Books Base as aThe same Books Base as a “Currently Reading” table view, sorted by start dateViews are cheap. Bases are the thing you maintain. I have around 20 Bases at the moment, helping me maintenance, project/task management, life tracking, reading, learning, publishing, and more!

Whenever you think “I need another Base”, ask first whether you actually just need another view on a Base you already have.

TIP: You can switch views from the dropdown at the top, reorder them by dragging (the first one is the default).

Filters work like a funnel: base-wide vs per-view

There’s a subtlety in that “root query” idea that’s worth making explicit, because it’s exactly what makes the “one Base, many views” model click. Bases give you two layers of filters, and they stack like a funnel.

  • Base-wide filterssit at the wide mouth of the funnel. They apply to every view at once and decide which notes even enter the Base in the first place.
  • View filterssit below. Each view inherits the base-wide filters automatically, then adds its own on top to narrow the set further.

My Books Base is the clearest example. The base-wide filter keeps only notes taggedbook. That set flows down into every single view. My “Currently Reading” view inherits those book notes, then adds its own filter forstatusisReading. My “Read This Year” view inherits the same book notes, then filters for a finish date since January 1st. One wide filter at the top; a different narrow filter per view underneath.

Get this right and you stop repeating yourself. You never re-state “only books” in five different places; you say it once at the base level, and every view refines from there. Change the base-wide filter and all your views update at once. Change a view filter and only that view moves.

One filter type beginners often miss: checkbox properties. A property that holds atrue/falsevalue (a checkbox in the Properties editor) can drive a filter directly. Add afavoritecheckbox to your notes, create a view that filters forfavoriteistrue, and you’ve got an instant “favorites” view with no new tags and no extra metadata. Booleans are the cheapest filter you can add.

Embedding a Base inside a note

A Base doesn’t have to live in its own file that you open like a separate tab. You can drop it straight into any note, the same way you embed an image.

  • Embed the whole Base with\!\[\[Books\.base\]\]. It renders inline, fully interactive.
  • Embed one specific view with\!\[\[Books\.base\#Currently Reading\]\]. The part after\#is the view name, so you can place different views of the same Base in different notes.
  • The same works inCanvas. Drop a Base on the canvas, and right-click the file name to pin a specific view.

I use this a lot. My weekly review note embeds my tasks Base. My reading note embeds the “Currently Reading” view. The data sits right where I’m already working, live, instead of in a separate tab I have to go open.

You can also dock a Base into a pane. Open a\.basefile, then drag its tab to the right edge of the window (or any pane) to keep it on screen while you work in the main pane. Combined with thethiskeyword (more on it below), a docked Base reacts to whichever note you’re reading: a permanent side panel that updates as you move around your vault.

(There’s also aBases: Insert new basecommand that creates a fresh Base and embeds it at your cursor in one step.)

Bases are only as good as your properties

A Base is a lens. Point a lens at something out of focus and you get a blurry picture, no matter how good the lens is. Your notes’ properties are the focus. If half your book notes useauthorand the other half useauthors, if some haveratingas a number and others as stars in the body text, ifstatusis “reading” in one note and “Reading” in another, your Base will be a mess. Not because Bases are bad, but because the data underneath is inconsistent.

This is the single biggest reason Bases disappoint at first. The views go up before the metadata is clean, so they faithfully display a mess.

So before you go deep on Bases, do the boring work:

  • **Decide your properties per note type.**Books getauthor,status,rating,pages,date\_started,date\_finished. Pick names and stick to them.
  • **Use the same values.**Ifstatuscan be “To Read”, “Reading”, or “Read”, make those the only three values. Templates help enormously here, because every new note starts consistent.
  • **Give every column a display name.**In the Base, never let a rawhealth\_sleep\_total\_minutesleak into the UI. Set adisplayNameof “Sleep Hours”. Every property you surface should have a friendly, Title-Case label.

Bases will punish every inconsistency you have. That sounds like a downside. It isn’t. Bases made me a better note-taker, not just a better dashboard-builder, because they gave me an immediate, visual reason to keep my metadata clean. The dashboard is the reward for the discipline.

Start simple. Clean up the properties of one note type, build one Base on top, and notice the difference. Then expand.

By the way, this is also why I advocate so much to get support for strongly typed notes in Obsidian and why I’ve actually built theObsidian Starter Kit plugin for Obsidian.

Formulas and functions: where lists become dashboards

Filtering and sorting give you better lists. Formulas turn those lists into dashboards.

Before the examples, it helps to know that a Base column can come from three places:

  • Note propertiesare your own frontmatter. You reference them by name, with no prefix:author,status,rating, and you can change the display label (e.g.,Sleep Hoursvssleep\_hours)
  • File propertiescome from the file itself:file\.name,file\.folder,file\.ext,file\.size,file\.ctime,file\.mtime,file\.tags,file\.links. You get these for free on every note.
  • Formula propertiesare virtual columns you define. They don’t exist in any note; the Base computes them on the fly. Reference another formula withformula\.<name\>.

That third kind is really powerful. It enables combining fields, making calculations, transformations, formatting, etc.

Writing a formula

Open thePropertiesmenu in the toolbar, chooseAdd formula, give it a name, and type an expression. A green checkmark means the syntax is valid. A simple one:

price_label: if(price, "$" + price.toFixed(2), "")

That reads thepriceproperty and, if it exists, shows it as$19\.90. If not, it shows nothing. You have the usual operators to work with: arithmetic (\+ \- \* /), comparison (\> < == \!=), and boolean (\! && \|\|).

The function toolbox

Functions are what make formulas expressive. A handful are global, called on their own:if\(\),now\(\),today\(\),date\(\),duration\(\),link\(\),image\(\). The rest are calledon a value, method-style, and which ones are available depends on the value’s type:

  • Date:\.format\("YYYY\-MM\-DD"\),\.relative\(\)(gives you “3 days ago”), and fields like\.year,\.month,\.day.
  • String:\.contains\(\),\.startsWith\(\),\.lower\(\),\.title\(\),\.replace\(\),\.split\(\),\.slice\(\).
  • Number:\.round\(\),\.floor\(\),\.ceil\(\),\.abs\(\),\.toFixed\(2\).
  • List:\.filter\(\),\.map\(\),\.reduce\(\),\.sort\(\),\.unique\(\),\.join\(\),\.contains\(\),\.length.
  • File:\.hasTag\(\),\.hasLink\(\),\.inFolder\(\), plus fields like\.name,\.mtime,\.tags,\.links.
  • Link:\.asFile\(\),\.linksTo\(\).
  • Object:\.keys\(\),\.values\(\),\.isEmpty\(\).
  • Regex:\.matches\(\).

The full reference is in the official docs (linked at the end). You don’t need to memorize it; you need to know the categories exist so you know what’s possible.

A few gotchas that cost me time early on, worth internalizing:

  • There’s no standalonelength\(\)oryear\(\). Use\.lengthon a string or list, and\.yearon a date.
  • It’sfile\.links(outgoing) andfile\.backlinks(incoming), notoutlinks/inlinks.
  • Numbers use methods, not functions:value\.round\(\), notround\(value\).
  • A formula can reference another formula (formula\.x), but never itself, directly or indirectly.

Real formulas from my vault

Here’s a real formula from my Health Base (included in theObsidian Starter Kit). It reads the sleep, energy, and mood I logged in a daily note and computes a single wellness score:

wellness_score: if(health_mood && health_energy_level && health_sleep_total_minutes,
  ((number(health_mood) + number(health_energy_level) +
    if(number(health_sleep_total_minutes) >= 420, 10,
    if(number(health_sleep_total_minutes) >= 360, 7,
    if(number(health_sleep_total_minutes) >= 300, 4, 2)))) / 3).round(),
  "Incomplete Data")

No note contains a “wellness score”. The Base computes it from data I already captured. And that’s what I love about formulas.

Two patterns I reuse everywhere:

**Time bucketing.**I have atime\_recencyformula that turns a note’s date into a label like10 \- 🆕 Today,20 \- 📅 This Week,30 \- 📆 This Month, and so on. I then group any view by that formula, and suddenly every dashboard has clean “Today / This Week / This Month” sections without any manual sorting.

**Reading duration.**My Books Base computes how long each book took:

days_reading: if(date_started,
  if(date_finished, (date(date_finished) - date(date_started)).days,
                    (today() - date(date_started)).days), 0)

If the book is finished, it measures start to finish. If I’m still reading, it measures start to today. That way the information is always current & relevant.

Grouping and summaries: from list to report

Two view options turn a flat list into a real dashboard: grouping and summaries.

Groupingcollapses your rows into sections by a property. Group your Books view bystatusand you get “Reading”, “To Read”, and “Read” as headers with their books underneath. Group a daily-notes view by mytime\_recencyformula and every entry files itself under “Today / This Week / This Month”. You set it with theGroup bycontrol in the view (orgroupByin the raw syntax).

Summariescompute one value per column, shown at the foot of a table; and when a view is grouped, at the foot of each group. Count the rows, sum the pages, take the median sleep, average a score. My “Read This Year” view sums total books and total pages. My Health Dashboard groups days by recency, then shows the median mood, energy, and sleep for each group, so I can compare this week against last month at a glance.

Summaries are set per view, per column, so the same property can show a sum in one view and a median in another. Grouping gives you the sections; summaries give you the numbers per section. Together they turn a list of entries into something you can actually read.

A useful convention

Bases sort text columns by character code. So if you label your buckets with emoji first (🆕 Today,🔴 Overdue,📅 This Week), they sort by the emoji’s code point, not by the order you actually want.

The fix is a small convention I apply to every rankable formula: prefix the label with a two-digit number.10 \- 🆕 Today,20 \- 📅 This Week,30 \- 📆 This Month. Use 10, 20, 30 rather than 1, 2, 3 so you can introduce a15in later without renumbering everything. Reserve99for “unknown” or “no data”.

This is the same convention that myObsidian Starter Kituses for statuses like10 \- Backlogand60 \- Completed, and it’s worth adopting from the get go.

When Bases beat Dataview (and when they don’t)

If you’ve been using Obsidian for a while, you’ve probably used theDataview. So the obvious question: should you switch? Here’s my opinion on that...

Reach for Bases when:

  • You want a visual, sortable, native dashboard with zero code.
  • You want to edit values directly in the view (Dataview is read-only; Bases let you change a property in the table and it writes back to the note).
  • Performance matters. Bases are fast, even on a 20,000-note vault, even on mobile.
  • You want to be able to tweak it through a user interface.

Still reach for Dataview (or DataviewJS) when:

  • You need logic that Bases formulas can’t express yet.
  • You want inline queries woven into the prose of a note rather than a standalone view.
  • You already have complex queries that work and aren’t worth rewriting.

One caveat on that editing point: not every column is editable in place. Formula columns are computed, so they’re read-only by nature. A few file properties (the file’s path, for instance) can’t be changed from the table either. But your own note properties; text, numbers, dates, checkboxes, tags; those you can edit right there in the view, and the change writes straight back to the note.

I still use theDataviewa lot, combined with myDataview Serializer plugin for Obsidian(for portability & data longevity). But I now leverage Bases for many use cases instead of Dataview. For roughly 80% of what I want from a dashboard (filtered, sorted, grouped views over typed notes), Bases is the better choice in 2026. Faster, native, editable, and no query language to learn.

Just choose the right tool for the right job.

Example 1: A reading library that maintains itself

My Books Base is the friendliest example of the “one Base, many views” idea.

The filter is simple: notes tagged as books. From there:

  • ACardsview uses each book’s cover image (a property pointing to a local image or URL) for a visual gallery.
  • ACurrently Readingtable shows only books withstatus: Reading, plus thedays\_readingformula so I can see what’s been sitting half-read for four months.
  • ARead This Yeartable filters to books finished since January 1st, with summary rows totaling the number of books and pages. The footer literally adds up my year of reading.
  • Separate fiction and non-fiction galleries, each just a filtered view of the same Base.

The Books Base grouped by status, with totals computed in the summary rowsThe Books Base grouped by status, with totals computed in the summary rowsI never “organize” my reading list. I change a book’sstatusproperty when I start or finish it, and every view updates itself. The database does the filing. Also, since all my book notes are Markdown files, I can just ask AI to update the properties for me.

Example 2: A health dashboard on top of daily notes

This is the Base I open most. My daily notes carry tons of health-related properties: sleep, mood, energy, stress, steps, and a lot more (many of which are synced automatically from my smart watch). I never created a “health database”. The data was already in my daily notes. I just created a Base that leverages the data.

That single Health Base has more than a dozen views, all over the same daily notes:

  • AHealth Dashboardgrouping every day by recency, with computed status columns (mood, energy, sleep, stress, ...) and median summaries.
  • ASleep Trackingview with sleep stages, quality, and interruptions.
  • AnExercise Trackingview that sums steps, distance, reps, active minutes, etc.
  • AHigh Wellness Daysview filtered to days where my computed wellness score was 7 or higher, so I can study what made the good days good.

One Health Base over daily notes, with computed status columns and summary mediansOne Health Base over daily notes, with computed status columns and summary mediansFiltered views likeFiltered views like “High Wellness Days” turn raw logs into pattern-finding toolsThe lesson generalizes: if you’re already capturing structured data in your daily notes, you’re already sitting on a database. A Base is how you get it all visible in one place.

But wait, there’s actually much more you can do with Bases!

Example 3: Custom Base views

Bases ship with Table and Cards views, with more coming from the Obsidian team (e.g., a Kanban view type they’re working on). But the Obsidian team isn’t the only one who can add views. Plugins can add entirely new Base view types, so the same query you already wrote can be rendered in completely new ways.

For instance, theTaskNotes plugin for Obsidiancomes with multiple new Base view types: a Kanban board for your tasks, a calendar, a tasks list, ...

Actually, I cared about this enough to build multiple Obsidian plugins that also add new Base view types.

Life Tracker plugin for Obsidianadds a “Life Tracker” Base view that turns tracked properties into charts: heatmaps, line, bar, area, radar, and more (twelve visualization types in total). Point it at the same daily-note data my Health Base reads, and instead of a table I get GitHub-style heatmaps of my habits and trend lines for sleep, energy, and weight.

The Life Tracker plugin renders Base data as charts and GitHub-style heatmapsThe Life Tracker plugin renders Base data as charts and GitHub-style heatmapsTrend lines computed from the same daily-note properties, no extra data entryTrend lines computed from the same daily-note properties, no extra data entryThat plugin also provides a data entry view:

Life Tracker plugin for Obsidian - life tracking gridThis goes further than merely listing the notes filtered by the base; it enables editing and validating all health-related properties.

Journal Bases plugin for Obsidianadds purpose-built views for daily, weekly, monthly, quarterly, and yearly notes, plus a periodic-review view. It makes navigating and runningPeriodic reviewsfeel native instead of like wrangling a generic table. It’s a clearly-defined process turned into a Base view.

The Journal Bases plugin adds dedicated periodic-notes and review viewsThe Journal Bases plugin adds dedicated periodic-notes and review viewsGraph Explorer Base View plugin for Obsidianrenders any Base as an interactive force-directed graph. Each note becomes a node, each link an edge. You can color nodes by any property, track which ones you’ve reviewed, and spot clusters and gaps at a glance. I built it for navigating AI-maintained wikis, but it works on any set of notes.

The Graph Explorer plugin renders a Base as an explorable knowledge graphThe Graph Explorer plugin renders a Base as an explorable knowledge graphThe point isn’t “use my plugins”. The point is that a Base is a stable, reusable query, and plugins can add new view types that enable visualizing/editing/... those notes in various ways. Your data remains in the notes themselves while the way to look at it keep multipliying.

Example 4: The AI Base

This is another Base that I’ve created for my own needs recently.

My vault doesn’t just hold notes. It holds AI agents, AI skills, commands, memory, etc. So I built a Base that indexes all of it.

The filter targets those hidden paths:

filters:
  and:
    - file.ext == "md"
    - or:
        - file.path.startsWith(".claude/agents/")
        - and:
            - file.path.startsWith(".claude/skills/")
            - file.name.startsWith("SKILL")
        - file.path.startsWith("10 Meta/99 AI Assistant/")

Then, formulas classify each file. One reads each skill’smetadata\.capabilityand groups by domain. Another computes afreshnesslabel from the file’s modification date (10 \- 🟢 Fresh,20 \- 🟡 Recent, all the way to50 \- ⚫ Very Stale). A “Needs Attention” view surfaces stale agent memory and aging skills automatically.

The AI Base indexes every agent and skill in the vault, classified and freshness-trackedThe AI Base indexes every agent and skill in the vault, classified and freshness-trackedThe result is a control panel for the AI system inside my vault, built entirely with a Base. No new app. No external dashboard. Just a query over Markdown files, including the ones Obsidian normally indexes nor shows.

This is what I mean when I say Bases are a lens. The same primitive that lists my books also runs the cockpit for dozens of AI agents. (If you want the full picture of how AI lives inside the vault, that’s theAI Assistant Systemin theObsidian Starter Kit, and the broaderset of OSK systemseach lean on Bases in their own way.)

Bases beyond the app: the Obsidian CLI

Another awesome fact is that Bases aren’t trapped inside the Obsidian app window. Using the officialObsidian CLI, you can actually query your Bases from the terminal (and/or from AI tools such asClaude Code,OpenAI Codex,GitHub Copilot,OpenClaw,Hermes, ...).

A few commands worth knowing:

# List every .base file in the vault
obsidian bases

# List the views inside the current base
obsidian base:views

# Query a base and get the results as JSON, CSV, or Markdown
obsidian base:query file="30 Areas/34 Maps/34.02 Bases/Books (Base).base" view="Read This Year" format=json

That last one is the interesting one.base:queryloads your Base, and gets data out of it:

❯ obsidian base:query file="30 Areas/34 Maps/34.02 Bases/Books (Base).base" view="Read This Year"

[
  {
    "path": "30 Areas/32 Literature notes/32.03 Book notes/The Night Window (book).md",
    "Note": "The Night Window (book)",
    "Title": "The Night Window",
    "Author(s)": "[[Dean Koontz]]",
    "Categories": "Fiction",
    "Pages": "610",
    "Pages (This Year)": "610",
    "Date Started": "2026-06-18",
    "Date Finished": "2026-06-23",
    "Days Reading": "5",
    "Rating": "★★★☆☆",
    "Notes": null
  },
  {
    "path": "30 Areas/32 Literature notes/32.03 Book notes/Never Lie (book).md",
    "Note": "Never Lie (book)",
    "Title": "Never Lie",
    "Author(s)": "Freida McFadden",
    "Categories": null,
    "Pages": "0",
    "Pages (This Year)": "0",
    "Date Started": "2026-06-01",
    "Date Finished": "2026-06-05",
    "Days Reading": "4",
    "Rating": null,
    "Notes": null
  },
  ...
]

You can then pipe the results to whatever you want: a script, an automation, an AI tool. Your “Read This Year” view can feed a year-in-review post. Your tasks Base can feed a morning briefing. The Base becomes a reusable data source for the world outside Obsidian, not just a view inside it.

This is the bridge between “pretty dashboard” and “automation building block”, and it’s a big part of why I lean on Bases so heavily.

Dynamic Bases withthis

Let’s discuss about a really cool feature of Obsidian Bases.

When you embed a Base inside a note, the Base can refer to that note asthis. When the Base sits in your sidebar,thisbecomes whichever note you’re currently looking at (i.e., the currently active/focused note).

That means a single Base can adapt its content to your context. The classic example is a smarter backlinks panel:

filters:
  and:
    - file.hasLink(this)

Drop that Base in your sidebar and it always shows the notes that link to whatever you’re reading. Open a different note, and it updates itself. One Base, infinite contexts.

Instead of building a dashboard per note, you build one context-aware Base and letthisdo the work. It’s one of the most underused features in all of Bases.

As an example, in my vault, I have a “Dynamic” Base that heavily uses thethiskeyword. Here’s what its “Tags” view shows for this very article:

Dynamic Base showing notes that have tags in common with the current noteDynamic Base showing notes that have tags in common with the current noteThat “Tags” view lists all the notes that have a relationship of some kind with the current note.

Tips & tricks worth knowing

A few small quality-of-life things I’ve picked up along the way. None of them are essential. All of them make working with Bases nicer day to day. Most are tucked away in menus and settings, so they’re easy to miss.

  • **Rename a view in one click.**Right-click the view’s button at the top to start editing it directly, no menu digging required.
  • **Reset a column width instantly.**Double-click a column divider in a table view and it snaps back to its default width. Very handy after you’ve been dragging things around.
  • **Control the row height.**Table views let you change the row height in the view settings. Compact when you want a dense dashboard, taller when you want some breathing room.
  • **Tune your card galleries.**In a Cards view’s settings, you can set both the cover image property and the card aspect ratio, so your bookshelf or gallery looks exactly the way you want it to.
  • **No cover image? Use a color.**The property feeding a Cards view’s cover doesn’t have to be an image. A hex color code works too (e.g.,color: "\#4555dd"). Perfect for notes that have no natural thumbnail; color-code them instead.
  • Reorder properties with the keyboard.With thePropertiesmenu open, move through the list with the arrow keys, and holdAlt/Optto push a property up or down. Much faster than the mouse once your views get long.
  • **Edit notes just by hovering.**If you have the Page Preview core plugin enabled, turn off Bases’ “Require Ctrl to trigger preview” option. Now you can see and edit a note’s preview simply by hovering over it in the Base, no clicking through.
  • **Make Bases match your theme.**The whole look and feel can be customized through CSS variables (linked in the references). If you live in your dashboards like I do, it’s worth a few minutes to make them truly yours.

Small stuff, but it adds up.

Let AI build Obsidian Bases for you

Writing Base syntax by hand is fine once you know it, and the user interface makes it a breeze to create or update one. But it takes time, and it’s easy to break things.

Steph Ango(Obsidian’s CEO) published a set of openAI Agent Skills:Obsidian AI Skills by Steph Ango. Those include anobsidian\-basesskill that teaches an AI assistant how to construct and edit\.basefiles: views, filters, formulas, and summaries included. You can find them atgithub.com/kepano/obsidian-skills.

With a skill like that loaded, building a Base becomes a conversation. “Make me a Base that shows my unfinished projects grouped by priority, with a column for days since last touched.” The AI writes the\.basefile, formulas and all. You review it, tweak it, ship it.

This is exactly how I work. I describe the dashboard I want in plain language and let AI draft the syntax, then I refine. It collapses the learning curve to almost nothing. The formulas I showed you earlier? You don’t have to memorize that syntax anymore. You have to know what question you want to ask. The AI handles the grammar.

Bases made dashboards code-free. AI is now making them description-free.

AI does make mistakes, it’s not perfect. But with a few attempts you’ll quickly get to what you want. And it’ll be even faster if you have clearly-defined note types like I have created for myself with theObsidian Starter Kit.

Going further

If you want a vault that’s set up for all of this out of the box (typed notes with consistent properties, 20+ ready-made Bases for books, health, people, tasks, and more, plus the AI layer that makes the AI Base possible), that’s exactly what I’ve built into theObsidian Starter Kit.

Obsidian Starter Kit - Stop Configuring, Start Thinking | Knowledge Forge AI-native Obsidian vault with AI agents, ~375 AI skills, LLM Wikis, 40+ auto-filing templates, and PKM methodology. 1,000+ users. 30-day guarantee. Knowledge ForgeDwayne Appleby The Starter Kit ships first-class Bases support across every system, so you get the property discipline and the dashboards without assembling them yourself.

The Obsidian Starter Kit ships with Bases supporting each of its systemsThe Obsidian Starter Kit ships with Bases supporting each of its systemsAnd if you want to go deeper with a community of people building knowledge systems like this, come hang out in Knowii.

Knowii Community - Master Knowledge Management + AI | From €14.99/quarter Join 450+ members mastering Knowledge Management AND AI. Community + Courses + Tools integrated. €500+ value in Knowledge Master tier. Knowledge ForgeSofia I also send a weekly newsletter on knowledge management, Obsidian, and AI-augmented thinking.

Sébastien Dubois DeveloPassion’s Newsletter by Sébastien Dubois. A weekly letter about knowledge work, AI, productivity, and building knowledge systems that compound. Sébastien DuboisBy ## Conclusion

Obsidian Bases aren’t a spreadsheet you fill in. They’re a lens you point at notes you already have. Get that one idea right and everything else follows.

The order that works: clean up your properties first, build one Base on top, add views instead of more Bases, then let formulas turn those views into real dashboards. Once that foundation is solid, Bases scale effortlessly, from ten notes to twenty thousand or more; from a reading list to a cockpit for the AI agents living in your vault.

Start with one note type. Tidy its properties. Build one Base. You’ll feel the shift immediately, and you’ll never look at your vault as a pile of files again.

That’s it for today! ✨


About Sébastien

I’mSébastien Dubois, and I’m on a mission to help knowledge workers escape information overload. After 20+ years in IT and seeing too many brilliant minds drowning in digital chaos, I’ve decided to help people build systems that actually work. Through theKnowii Community, mycourses,products & servicesand my Website/Newsletter, I share practical and battle-tested systems.

I write aboutKnowledge Work,Personal Knowledge Management,Note-taking, Lifelong Learning,Personal Organization,Productivity, and more. I also craft lovelydigital productsandtools.

If you want to follow my work, thenbecome a memberandjoin our community.

Ready to get to the next level?

Since you’re interested in Obsidian:

Similar Articles

@cyrilXBT: https://x.com/cyrilXBT/status/2069603314744926535

X AI KOLs Timeline

A detailed guide covering 50 advanced Obsidian workflows, plugins, and setups, including Dataview queries, Templater automation, and Canvas spatial thinking techniques, aimed at transforming Obsidian into a personal operating system.

@chaosgrmln: https://x.com/chaosgrmln/status/2074407657146884216

X AI KOLs Timeline

A practical guide to structuring an Obsidian vault with three core files (me.md, vault map, skill map) to make Claude's queries more accurate, moving beyond reliance on large context windows to a systematic approach for personal AI note-taking.