Obsidian Bases: the complete guide to database views (2026)

Most people do not realize they need Bases until folders, tags, and search stop feeling like a system and start feeling like a pile. The breakthrough is not "I need a database." The breakthrough is "I want the same Markdown notes to behave like a project board, reading list, CRM, or travel planner without leaving Obsidian."

Obsidian Bases is the point where your notes become operational. It is a core plugin for database-like views over files and properties: tables, cards, lists, and maps. Your data stays in local Markdown, while the view logic lives in a .base file or an embedded base code block. Start with the official overview: Introduction to Bases.

Fix it fast

If you already have a broken base and do not need the full guide yet:

Fastest triage: Bases Debugging Cheat Sheet
Highest-intent fix guide: Obsidian Bases filter not working
Jump to templates: 6 copy/paste base templates

Screenshot: the command palette with "Bases: Create new base" and "Bases: Insert new base" highlighted. This matters because readers need to see the 2 fastest entry points before the rest of the guide feels concrete.

What Bases is (and is not)

Bases is:

A core plugin that lets you view, edit, sort, and filter files and their properties (Introduction to Bases).
Backed by note properties (frontmatter), file metadata, and formulas (Bases syntax, Formulas).
Configurable with multiple views (table/cards/list/map) (Views).

Bases is not:

A separate database. Notes are still the source of truth.
A SQL engine with FROM. Bases starts broad (all files) and narrows with filters (Bases syntax).

If you are comparing tools: see Dataview to Bases migration playbook.

Quick start: build your first base in 5 minutes

1) Create a base

Use the documented workflows: Create a base.

Fastest workflow:

Command palette -> "Bases: Create new base"
Give it a name like "Projects.base"

2) Add a single dataset filter immediately

A base without filters can show everything in your vault (Views).

Pick one dataset definition:

folder: file.inFolder("Projects")
tag: file.hasTag("project")
type property: type == "project"

Use the safe YAML style (quote filter statements):

filters:
  and:
- 'type == "project"'

3) Add a table view and show 5 columns

Start with:

file.name
2-3 note properties you care about
1 file property for debugging like file.path (remove later)

Official file properties list: Bases syntax.

4) Embed the base where you work

Embed a .base file:

![[Projects.base]]
![[Projects.base#Active projects]]

Official embedding: Create a base.

Minimal debug base

Before you assume "Bases is broken," force the vault to show you what the base can actually see.

views:
- type: table
  name: Debug
  filters:
    and:
	- 'file.ext == "md"'
	r:
	- file.path
		- file.folder
			- file.tags
				- file.links
		mit: 50

What this reveals immediately:

whether the files are actually in the folder you think they are
whether the files actually have the tags you are filtering for
whether links and paths look the way your later filters assume

Screenshot: a temporary Debug view showing file.path, file.folder, file.tags, and file.links. This matters because it turns invisible metadata assumptions into visible evidence in one glance.

How Bases works (mental model)

If you remember only two rules:

Rule 1: Bases starts with "all files", then filters down

There is no FROM clause. Filters define your dataset (Bases syntax).

Rule 2: Global filters and view filters are combined with AND

"All views" filters define the dataset.
"This view" filters define a slice.
They are concatenated with AND at evaluation time (Bases syntax).

Deep dive: Advanced filter patterns

Bases vs Dataview vs Search

If you choose the wrong tool, Bases will either feel too limited or more complicated than it needs to be. Start with this matrix.

Tool	Best when	Editing in place	Data model	Query style	Main tradeoff
Bases	You want editable, database-like views over files and properties	Yes	Files + properties + formulas	UI filters + YAML syntax	Rows are still files
Dataview	You want more expressive querying and computed views	Mostly no	Indexed metadata, including inline fields	DQL, inline queries, DataviewJS	More code and more abstraction
Search	You want the fastest retrieval layer and operator-based triage	No	Note and canvas content, paths, files, properties	Search operators	Not a database view

Use Bases when

you want editable views
you want one source of truth in note properties
you want dashboards that live inside notes with this

Use Dataview when

you need query flexibility beyond what Bases expresses comfortably
you rely heavily on inline fields
you want code-driven or analytics-heavy views

Use Search when

you need the fastest possible retrieval
you want operators, regex, and ad hoc investigation
you do not need a persistent view layer

Related: Dataview to Bases migration playbook

Properties and schema design that does not break

Properties are YAML frontmatter metadata managed by Obsidian (Properties).

Bases uses three categories:

note properties (frontmatter)
file properties (metadata)
formula properties (defined in the base) (Bases syntax)

7 schema rules that prevent most breakage

Prefer a stable "record definition"

Best: type: project and filter type == "project"
- Folder and tag datasets are great too, but are easier to drift during refactors.

Choose link vs text and be consistent

If project should reference another note, store it as a link everywhere.

Choose list vs single value and be consistent

If attendees is a list, keep it a list even when it has one value.

Normalize inconsistencies defensively in filters/formulas

Use list(property) when a field might be scalar or list (Functions).

Learn the two tag systems now (saves hours later)

tags.contains() targets a frontmatter property named tags
- file.hasTag() targets file tags and supports nested tags (Tags, Functions)
- Deep dive: Tags in Bases

Keep a Debug view you can toggle on/off

Show file.path, file.folder, file.tags, file.links while building.
- Reference: Bases syntax

Do not trust old snippets blindly

Bases functions changed in early versions; prefer official docs plus up-to-date patterns from active community guides.
- Reference example: Bases Migration/Quick Start Guide

Create and embed Bases

Create a .base file

Official workflow: Create a base

Embed a base file

![[My Base.base]]
![[My Base.base#View Name]]

Official: Create a base

Embed inline (template-friendly)

You can embed a base as a code block using the Bases syntax (Create a base, Bases syntax):

```base
filters:
  and:
- 'file.hasTag("example")'
views:
- type: table
  name: Table
  limit: 50
```

Advanced reuse (block embedding discussion): Embed base code block in another note

Views: table, cards, list, map

Official view overview: Views

Screenshot: the Bases toolbar with View, Results, Sort, Filter, Properties, and New highlighted. This matters because this toolbar is the control plane for almost every user action the rest of the guide explains.

Add this note directly under the opening paragraph:

Note: officially documented built-in layouts currently include Table and Cards in Obsidian 1.9, plus List and Map in 1.10; Map also requires the Maps plugin.

Table view (editing + summaries)

Table view is the workhorse for editing properties and analyzing with summaries. Reference: Table view

Deep dive: Grouping and list property display

Cards view (covers, galleries)

Screenshot: Cards view settings with Image property, Image fit, and Image aspect ratio visible. This matters because image formatting and missing covers are one of the most common support failures for Bases galleries.

Cards support an optional cover image. Image property formats: attachment link "[[...]]", URL, or hex color (Cards view).

Deep dive: Cards view cover images

List view (dashboards, MoCs)

Reference: List view

Map view (places, travel, field notes)

Screenshot: Map view settings showing marker coordinates, marker icon, and marker color. This matters because a blank map is usually a property-to-setting mismatch, not a conceptual problem with the base itself.

Map view requires the Maps plugin and expects coordinates in specific formats (Map view).

Deep dive: Map view for places

Filters: reliable patterns (and gotchas)

Official filter language and examples: Bases syntax and Views

The 6 filter primitives that cover most needs

Folder scope

- 'file.inFolder("Projects")'

Tag scope (file tags, supports nested tags)

- 'file.hasTag("project")'

Backlinks-style "notes linking to this note"

- 'file.hasLink(this.file)'

"Only this file" dashboard

- 'file.path == this.file.path'

Date windows

- 'due && due <= today() + "7d"'

Nested logic (and/or/not)
Use YAML groups:

filters:
  or:
- 'status == "Active"'
	- 'status == "Paused"'

Deep dive: Advanced filter patterns and Date filters

The 4 gotchas that cause most "filter not working" tickets

Scope: dataset filter applied to one view, but you are looking at another view
this: you embedded the base and this changed meaning (Bases syntax)
tags: you used tags.contains when you meant file.hasTag (Tags)
types: link vs string or list vs scalar mismatch (fix with list()) (Functions)

Fix guide: Obsidian Bases filter not working

Screenshot: the Filter menu with both "All views" and "This view" visible. This matters because scope confusion is the single fastest explanation for "my base shows everything" versus "my base shows nothing."

Immediately after that block, add this short callout:

Gotcha: if your dataset definition lives in "This view" and you switch to a different view, it can look like filters stopped working. Keep dataset filters in the global filters section and slice filters in each view.

Formulas: practical patterns

Screenshot: the formula editor with autocomplete suggestions and a green validity check visible. This matters because readers need to see that formulas are validated inline and can be used just like any other property in views, sorting, and filters.

Official: Formulas and Functions

5 formulas worth adding to almost every base

Overdue flag

formulas:
  overdue_flag: 'if(due && status != "Done" && due < today(), "Overdue", "")'

Due in days

formulas:
  due_in_days: 'if(due, ((due - today()) / 86400000).round(), null)'

Updated relative

formulas:
  updated: 'file.mtime.relative()'

Safe list contains

formulas:
  has_this_attendee: 'list(attendees).contains(this)'

Canonical group key for list grouping

formulas:
  canonical_area: 'list(area).unique().sort().join(", ")'

Deep dive: Formula examples

Dashboards with this (context-aware)

this changes based on where the base is displayed: open base, embedded base, or sidebar (Bases syntax).

Use this for reusable dashboards:

Project note: show tasks linked to this project
Person note: show meetings where attendees contains this person
Any note: show notes that link to this note

Complete example: People + Meetings

This is the simplest example that makes this click.

A Person note

---
type: person
company: "[[Acme Inc]]"
role: VP Product
---

A Meeting note

---
type: meeting
date: 2026-02-12
attendees:
- "[[Ada Lovelace]]"
	- "[[Grace Hopper]]"
project: "[[Project Alpha]]"
---

The Meetings base view

views:
- type: table
  name: Meetings for this person
  filters:
    and:
	- 'list(attendees).contains(this)'
	r:
	- date
		- file.name
			- project
		mit: 200

The embed inside the Person note

![[Meetings.base#Meetings for this person]]

When that view is embedded in a Person note, this becomes the embedding file, so the same view automatically becomes "meetings where attendees contains this person."

Screenshot: a Person note with an embedded "Meetings for this person" table visible. This matters because it demonstrates this in the exact context that confuses most readers.

Related: Advanced filter patterns

Performance and scale

Prefer smaller datasets and view limits while iterating (Views)
Avoid performance-heavy fields like file.backlinks unless necessary (Bases syntax)
Cards view + many images can stress mobile; narrow scope and limit rows (example discussion: https://forum.obsidian.md/t/bases-in-card-view-crash-on-mobile-if-it-has-to-render-many-images-including-gifs/105041)

Export and automation (CSV + CLI)

View exports and copy-to-clipboard are supported via the view UI (Views).
The official Obsidian CLI supports automation (early access requirements apply). See Obsidian CLI.

Deep dive: Obsidian CLI + Bases automation

6 copy/paste base templates

Templates included:

Projects
Tasks
Meetings (includes "meetings for this person" view)
People CRM
Reading list (table + cards)
Places (table + map)

Use the templates section from the prior draft (unchanged YAML) or place each template on its own page for better SEO and reuse.

Troubleshooting Bases (fast triage)

Need the fastest route to the fix? Jump straight to your symptom:

For the full support flow:

Bases Debugging Cheat Sheet
Obsidian Bases filter not working

Base shows every file in the vault

A base without filters can show every file in the vault. Start by checking whether your dataset filter lives in the global filters section or only in one view.

Base shows zero files

Start with the Minimal debug base above, then re-add folder, tag, or type filters one by one.

Embedded base behaves differently

Check this context first. In an embed, this refers to the embedding file, not the base file itself.

Tags do not match what you expect

Double-check whether you meant tags.contains() for a frontmatter property or file.hasTag() for real file tags.

Cards view shows no images

Verify the image property format and the Cards "Image property" setting.

Map view is blank

Verify Map view requirements, coordinate format, and marker property mapping.

FAQ

What are Obsidian Bases?

Bases is a core plugin for database-like views over notes and their properties. See Introduction to Bases.

How do I create a base in Obsidian?

Use the workflows documented in Create a base.

How do I embed a base in a note?

Use ![[File.base]] or ![[File.base#View]]. See Create a base.

What does `this` mean in Bases?

this depends on context: open base, embedded base, or sidebar. See Bases syntax.

Why does my base show every file in the vault?

Usually because the base has no dataset filter, or because the filter lives only in one view. Start with Obsidian Bases filter not working.

Why does my base show zero files?

Usually because your dataset filter is too strict, this is pointing at the wrong file, or you have a type mismatch. Use Bases Debugging Cheat Sheet.

What is the difference between `file.hasTag()` and `tags.contains()`?

file.hasTag() targets actual file tags, including nested tags. tags.contains() targets a frontmatter property named tags. See Tags in Bases.

When should I use Search instead of Bases?

Use Search when you need fast retrieval, ad hoc investigation, operators, or regex rather than a persistent view layer. See Search.

When should I use Dataview instead of Bases?

Use Dataview when you need query flexibility, inline field support, or more code-driven views. See Dataview to Bases migration playbook.

Can I export Bases to CSV?

Yes. The Views UI supports export and copy actions. See Views.

Can I automate Bases with the Obsidian CLI?

Yes, if the CLI prerequisites apply to your setup. See Obsidian CLI and CLI automation.

Why are my Cards images missing?

Check the Cards image property format and settings first. See Cards view cover images.

Why is my Map view blank?

Check the Maps plugin requirement, coordinate format, and marker property mapping. See Map view for places.

References

Official:

High-signal community threads used for recurring query phrasing: