Obsidian Bases: How to Build No-Code Databases in Your Vault

If you have spent any time wrangling notes in Obsidian, you have probably wished your vault behaved more like a database. You want every active project in one place, your reading list filtered by status, or every meeting note tied to a specific person, all without writing a line of query code. That is exactly what Obsidian Bases gives you: native, no-code database views built on top of the Markdown notes you already have.

Bases is the natural evolution of connected notes. Where links knit your vault into a graph, properties turn that graph into structured data you can slice and filter. A base does not store your information in a separate file or proprietary format. It reads the YAML properties already living in your notes and presents them as an editable, filterable table, card gallery, list, or map. Your data stays plain-text, portable, and future-proof.

Here is what we will cover:

• What a base actually is, and the mental model that makes everything click
• How Bases compares to Dataview, Notion, and plain search
• Enabling the plugin and building your first base in five minutes
• Designing properties so your views never break
• Filtering, sorting, and grouping your notes
• The four view types and how to embed them in any note
• Copy-pasteable use cases: reading list, project tracker, CRM, content calendar
• Honest limitations and a clear decision framework

What Is Obsidian Bases (and Why It Matters)?

A base is a saved, no-code database view layered over your existing Markdown notes. Obsidian added Bases as a core plugin, and it turns your notes plus their YAML properties into editable, filterable views with no query language at all.

The single most important thing to grasp is the mental model: a base is not a separate database that stores your data. It is a view. The data itself lives in the frontmatter (the YAML properties) of your regular notes. The .base file only saves the configuration of how you want to look at those notes: which ones to include, which properties to show as columns, how to filter and sort them.

This matters for a few reasons:

• Your data stays plain-text. Delete the base tomorrow and you lose nothing but the view. Every note and every property is still sitting in your vault as Markdown.
• It is future-proof. No lock-in, no export step, no proprietary database format. This is the same philosophy that makes Obsidian a strong foundation for a lasting personal knowledge management system.
• It scales with your vault. Because a base reads live from your notes, the moment you add a property to a note, that note can appear in the relevant view.

If links are the connective tissue of your vault, properties are the structured layer, and Bases is the lens that makes that structure visible and usable.

Bases vs Dataview: No-Code GUI or Query Language?

The core difference is simple: Bases is a visual, point-and-click GUI, while Dataview is a query language you write by hand. Bases is built into the app and requires zero code; Dataview asks you to learn DQL (Dataview Query Language) or even JavaScript for advanced cases.

Both read from the same source, your note properties, but they suit different temperaments:

• Bases wins on speed and approachability. It is native, so it is fast, including on mobile. You build views by clicking, edit cell values inline right in the table, and never debug a syntax error.
• Dataview wins on expressiveness. It supports inline fields (like due:: 2026-06-10 in the body of a note), renders computed text, and handles complex bespoke queries Bases cannot yet match. It is, however, code-heavy.

For most "show me a filtered list of my notes" jobs, Bases is now the faster, friendlier choice. For deeply computed dashboards or inline-field workflows, Dataview still earns its place. If you are weighing how each fits a wider workflow, our task management guide shows where structured queries pay off.

Tip: You do not have to choose. Many vaults run Bases for everyday list-and-filter views and keep a few Dataview blocks for the one or two dashboards that need heavy computation.

How Do You Enable and Create Your First Base?

Enable Bases in Settings, Core Plugins, then toggle on "Bases." While you are there, enable "Properties" too, since clean properties are what make Bases shine. Once enabled, there are three ways to create a base:

1. Command palette: open it (Ctrl/Cmd + P) and run "Create new base."
2. Ribbon button: click the "New base" icon in the left ribbon.
3. Right-click a folder: choose "New base" from the folder context menu to scope it there from the start.

Here is the behavior that trips up newcomers: a new base starts from all files in your vault. There is no FROM clause like in Dataview. You start broad and filter down.

A five-minute first base looks like this:

1. Create the base with any method above.
2. It opens showing every note in your vault. That is overwhelming, and expected.
3. Add one filter to scope it, for example "file is in folder Projects" or "has tag #project."
4. Add a few columns by picking the properties you care about (status, due date, area).
5. Sort by one column, and you are done.

That is genuinely all it takes to get from zero to a working database view.

Tip: Start narrow. A base scoped to a single folder or tag is far easier to reason about than one trying to show your whole vault at once.

How Should You Design Properties That Won't Break?

Columns in a base come from three sources, and knowing them saves a lot of confusion:

• Note properties: the YAML frontmatter you write in each note (status, priority, due). These are editable.
• File properties: built-in metadata like file.path, file.ctime, file.mtime, and file.tags. These are read-only.
• Formula properties: values derived inside the base itself from other properties.

Supported property types include text, list, number, checkbox, date, date and time, and links. Picking the right type matters: a date property can be filtered by date windows, while the same value stored as plain text cannot.

The real prerequisite for reliable bases is property hygiene. A base is only as clean as the data underneath it:

• Be consistent with types. Do not store a value as a link in one note and plain text in another, or as a list in one and a scalar in the next. Mixed types make columns behave unpredictably.
• Name properties identically across notes. status, Status, and state are three different columns. Pick one and stick with it.
• Edit inline. Change a value directly in a base cell and it writes straight back to the note's frontmatter, so the base doubles as a fast editing surface.

This is where a good template system pays off. If your notes are created from templates with consistent properties, every future base becomes trivial to build because the schema is already uniform. Setting up your vault for Bases is really just setting up your properties well.

Note: Older notes created before you adopted a property will simply be missing that field. They still appear in the base; the column just shows empty until you fill it in.

How Do Filters, Sorting, and Grouping Work?

Filters in Bases are built from a three-part rule: property, operator, value. You choose a property (like status), an operator (is, contains, is greater than, is empty), and a value (active). You can nest multiple rules with and, or, and not to express exactly the slice you want.

There are two levels of filtering:

• Global (dataset) filters apply to the entire base, across every view. Use these to define the universe of notes the base cares about, for example "is in folder Projects."
• Per-view filters apply to a single view and combine with the global filter using AND. Use these to make one view show only active items while another shows the archive.

Common patterns you will reach for constantly:

• Has tag: filter where file.tags contains #project.
• Folder scope: filter where the file is in a specific folder.
• Date window: filter where due is on or before today, or within the next seven days.

Sorting works on any column, ascending or descending. Grouping lets you cluster projects by status, books by genre, or tasks by priority, and each group gets its own collapsible heading.

Tip: Build your global filter first to define the dataset, then add lightweight per-view filters for each lens (Active, Done, This Week). It keeps each view focused without duplicating logic.

What Are the Four View Types, and How Do You Embed Them?

Bases supports four view types, and a single .base file can hold several named views side by side. You switch between them with tabs inside the base.

• Table: the default. Rows and columns with inline editing and column summaries (counts, sums). Best for dense, structured data like a project tracker.
• Cards: a gallery layout that can show cover images. Perfect for a reading list or anything visual.
• List: a lightweight, compact layout ideal for dashboards and maps of content (MoCs).
• Map: plots notes that carry location coordinates as geographic pins.

The real power comes from embedding. You can drop a base into any note exactly like an embedded file using the .base filename in an embed. To embed one specific named view rather than the whole base, append the view name with a #, for example MyBase.base#Active.

There is also a context-aware this reference. An embedded base can filter relative to the note it lives in, so a base embedded inside a person's note can show only the meetings linked to that person. We use exactly that trick in the CRM example below.

Embedding is what turns a base from a standalone page into a living component of your notes. A daily note can embed a "due today" view; a project note can embed its own task list. If you are building dashboards this way, our guide to Obsidian project management shows how these views fit into a complete project workflow.

If you would rather not assemble every base, filter, and template by hand, Obsibrain ships preconfigured dashboards, property schemas, and PARA folders so the structure is already in place the moment you open your vault.

What Can You Actually Build?

You can build almost any "list and filter my notes" tool you would otherwise reach for Notion to make. Here are four concrete setups with the exact properties to add so you can replicate them today.

Reading list / digital bookshelf

• Properties: title (text), author (text), status (text: to-read / reading / done), rating (number), cover (link to an image)
• Use a Cards view so covers show as a gallery, grouped by status.

Projects tracker

• Properties: status (text: planning / active / on-hold / done), area (link), due (date), priority (number)
• Use a Table view, group by status, sort by due ascending.

Lightweight personal CRM (worked example)

• People notes carry: type: person, company (text), email (text), last-contact (date)
• Meeting notes carry: type: meeting, attendees (list of links to people), date (date)
• Create one base filtered to type is meeting. Then embed that base inside each person note, using a per-view filter on attendees that references this (the current note). Now every person note automatically shows the meetings that person attended, with no manual linking lists required.

Content calendar

• Properties: stage (text: idea / draft / scheduled / published), publish-date (date), channel (text)
• Use a Table grouped by stage, sorted by publish-date. Filter out published items in your working view to keep your pipeline clean.

Each of these is just a folder of notes with consistent properties plus one base. That is the whole trick, and it is why a clean second brain template makes these almost free to set up.

Bases vs Notion: When Should You Use Each?

Bases is local-first, free, and works over your entire existing vault by default, while Notion is cloud-based and asks you to build siloed databases up front. With Bases there is nothing to export, because your data is already plain Markdown on your disk. Notion, by contrast, wins on true relational databases, a real external REST API for automation, and multi-user collaboration. Bases has no external API, only an internal plugin API.

Here is the honest, at-a-glance decision framework:

Tool	Use it when…
Plain Search	You just need to find a note or text once, not maintain a view.
Bases	You want a no-code, filterable list/table/gallery of your notes (most cases).
Dataview	You need inline fields or complex computed output Bases can't do.
Notion	You need true relational databases, an external API, or team collaboration.

Current limitations, to be honest about:

• Frontmatter only. Bases reads YAML properties, not Dataview-style inline fields written in the note body.
• Weaker computed output. Formulas exist but do not match Dataview's rendered, scripted flexibility.
• Fewer relation features than Notion. You link notes, but there is no two-way relational schema with rollups.
• Still maturing. Bases is young; expect the feature set to keep growing.

The decision rule is simple: use Bases for most of your list-and-filter jobs, reach for Dataview only when you need inline fields or heavy computation, and choose Notion only if you genuinely need relational databases or real-time team collaboration. For a fuller side-by-side, see our Obsidian vs Notion comparison.

If you want all of this working out of the box, Obsibrain is the ready-made template that combines PARA folders, GTD and Eisenhower task management, periodic planning, and prebuilt database views, so you get the payoff of Bases without spending a weekend wiring up properties and filters yourself.

Frequently Asked Questions

Is Obsidian Bases free? Yes. Bases is a built-in core plugin that ships with Obsidian. There is no paid add-on, no separate license, and no sync subscription required. You just toggle it on in Settings, Core Plugins.

Can Bases replace Dataview? For most filtered-list and table use cases, yes. If your goal is to show, filter, sort, and group your notes, Bases now does that natively and faster. Keep Dataview only when you need inline fields (values written in the note body) or complex computed and rendered queries Bases does not yet support.

Do Bases work on mobile? Yes. Bases is native, which makes it notably faster on mobile than Dataview, which can lag on large vaults. The one caveat is that image-heavy card views can be slower to render on phones, so lightweight table or list views are often the better mobile choice.

Where is the data in a base stored? In your notes' YAML frontmatter properties. The .base file only stores the view configuration: filters, columns, sorting, and grouping. Your actual data never leaves your Markdown notes, which keeps it plain-text, portable, and safe even if you delete the base.

Conclusion

Bases brings the database power people love about Notion into a local-first, plain-text vault, with no query language to learn. Treat it as the visible layer over good property hygiene: name your properties consistently, keep types clean, and lean on templates so every new base is trivial to build. Just as links turned your notes into a connected graph, properties turn that graph into structured, queryable data, and Bases is the lens that makes it usable. Start with one small base today, a reading list or a project tracker, and let the habit grow from there.