Obsidian Bases vs Dataview: Which to Use in 2026

You have a vault full of notes and you want to see them as a table you can sort and filter, not a wall of files. In 2026 you have two ways to do that in Obsidian: Bases, the core feature Obsidian ships in the app, and Dataview, the community plugin most power users have run for years. They overlap enough to confuse anyone setting up a database view for the first time, and they differ enough that picking wrong means rebuilding your queries later.

This guide breaks down exactly what each one does, where each wins, and which to reach for based on what you are actually trying to build. No hand-waving, just the tradeoffs and copyable examples.

Key takeaways

• Bases is a core Obsidian feature (no plugin install, no sync risk) that turns note properties into sortable, filterable tables and cards. Dataview is a mature community plugin with a full query language and inline JavaScript.
• Pick Bases if you want a stable, visual, GUI-driven database view that survives Obsidian updates and works on mobile without setup.
• Pick Dataview if you need complex logic, calculated fields, inline queries inside note bodies, or output that Bases cannot express yet.
• Bases reads YAML frontmatter properties. Dataview reads both frontmatter and inline key:: value fields, which matters if your vault already uses inline fields.
• Both are static views over your own vault. They show what you typed, they do not keep facts current or hand structured context to an AI tool. That gap is the real limit, and it is separate from which query tool you pick.

---

What Obsidian Bases actually is

Bases is Obsidian's built-in way to turn a set of notes into a database view. It shipped as a core feature, which means it is maintained by the Obsidian team and ships inside the app rather than as a third-party plugin you install and update yourself.

A Base is a saved view definition, stored in a .base file, that collects notes matching a filter and displays their properties as columns. You build the view through the interface: choose which notes to include, add columns from your note properties, set filters, and switch between a table layout and a card layout. Because it reads standard YAML frontmatter properties, any note with properties can appear in a Base without extra syntax inside the note body.

The important detail for a decision in 2026: Bases is newer than Dataview, so the ecosystem of examples, formulas, and edge-case tricks is thinner. It covers the common cases well (a reading list, a project tracker, a contacts table) and does it with a visual builder instead of a query language. If you have ever bounced off Dataview because you did not want to learn a query syntax, Bases is the answer to that specific frustration.

What the Dataview plugin actually is

Dataview is a community plugin that has been the default answer to "how do I query my vault" for years. You install it from the community plugins directory, and then you write queries inside code blocks in your notes.

It gives you two things Bases does not. First, a dedicated query language (DQL) with commands like TABLE, LIST, TASK, and CALENDAR, plus WHERE, SORT, GROUP BY, and FLATTEN clauses. Second, DataviewJS, which lets you write real JavaScript against your vault's data for anything the query language cannot express. It also reads inline fields written as key:: value anywhere in a note, not just frontmatter, so vaults built around inline fields lean on it heavily.

The tradeoff is that Dataview is a plugin, so it depends on a maintainer, it can lag behind Obsidian updates, and queries render live every time you open a note, which can feel slower in large vaults. For many people that tradeoff has always been worth it because nothing else matched its flexibility.

Bases vs Dataview: the side-by-side

Here is the honest comparison across the dimensions that actually change your decision.

When to use Bases

Reach for Bases when the view matters more than the logic. Concrete cases:

• You want a table of all notes tagged book with columns for author, status, and rating, and you want to build it by clicking, not by writing a query.
• You are on mobile a lot and want something that works without wrestling a plugin into place.
• You want a view that will not break the next time Obsidian updates, because it is a core feature rather than a third-party add-on.
• You are handing your vault to someone less technical, or your future self a year from now, and you want the view to be legible without knowing DQL.

Bases is the low-friction default. If your first instinct was "I just want a spreadsheet view of these notes," start here and only move on if you hit a wall.

When to use Dataview

Reach for Dataview when you need logic Bases cannot express yet. Concrete cases:

• Calculated columns: days since a note was created, a rollup that counts linked tasks, a field derived from two other fields.
• Inline queries embedded in a daily note or a dashboard note, so the query renders right where you read.
• Task queries across the whole vault (TASK WHERE !completed), grouped by file or by due date.
• Vaults already built on inline key:: value fields, since Dataview reads those natively and Bases keys off frontmatter properties.
• Anything genuinely custom, where DataviewJS lets you write JavaScript against the data.

If you already run Dataview and it works, there is no urgency to migrate. The two can coexist in the same vault. Use Bases for the clean visual tables and keep Dataview for the queries that need real logic.

Copyable examples

Here is roughly the same intent expressed in each tool, so you can see the difference in feel.

Dataview, written in a code block inside a note, listing every book you rated 4 or higher, sorted by rating:

TABLE author, rating, status FROM #book WHERE rating >= 4 SORT rating DESC

For that to work, each book note needs properties. In frontmatter that looks like:

---
author: Ursula K. Le Guin
rating: 5
status: finished
tags: [book]
---

In Bases, you would not write that query as text. You create a .base view, set the filter to notes tagged book with rating greater than or equal to 4, add author, rating, and status as columns, and sort by rating in the view settings. The frontmatter above is identical; the difference is that Bases builds the table through the interface and saves it as a reusable view, while Dataview regenerates it from the written query each time the note opens.

The practical read: if you can describe the table in one sentence and it needs no math, Bases gets you there faster. If the table needs a derived value or lives inline inside a working note, Dataview is still the tool.

The limit both share

Here is the part most comparisons skip. Bases and Dataview are both static views over data you already typed. They query your vault, they do not maintain it. A Base showing "current pricing" or "active clients" is only as current as the last time you edited those notes by hand. The moment your pricing changes, a project ships, or your opinion flips, the query keeps returning the old value until you go back and update the underlying notes. The query is live; the facts inside it are not.

That is fine when the goal is a personal reading list. It becomes a real problem the moment you want an AI tool to work from your notes, because a stale table feeds stale context, and the model has no way to know the row is out of date. This is the difference between a query engine and a second brain that stays current on its own.

Locul takes the second path. It builds a searchable second brain from what you already produce, including your local markdown files with their #tags and [[wikilinks]], and keeps it current with a supersedence model: when a fact changes, the old version is marked superseded and the history is preserved, so what your AI reads is the current fact rather than whatever you last remembered to edit. It then serves that brain to your AI tools over MCP with tools like search_notes and recall_memories, and it reads your data wherever it lives instead of forcing everything into one vault. If your endgame is "my AI should answer from my real, up-to-date context," a query view is the wrong layer to solve it at. For the deeper version of that argument, see how to give your AI a memory that actually lasts. If you have ever bought a bundle of frozen prompts and watched it age, the same staleness problem shows up there, covered in prompt packs vs memory packs.

---

FAQ

Is Obsidian Bases a plugin I have to install?

No. Bases is a core Obsidian feature that ships inside the app, so there is nothing to install or enable from the community plugin directory. Dataview, by contrast, is a community plugin you install and keep updated yourself. That difference is the main reason Bases is more resilient to Obsidian updates.

Can I use Bases and Dataview at the same time?

Yes. They read the same underlying notes and do not conflict. A common setup is to use Bases for clean visual database tables and keep Dataview for queries that need calculated fields, inline embedding, or JavaScript. There is no need to migrate everything to one or the other.

Does Bases read the same properties as Dataview?

Bases reads YAML frontmatter properties. Dataview reads frontmatter properties too, but it also reads inline key:: value fields written anywhere in a note body, which Bases does not use. If your vault is built heavily on inline fields, Dataview will see data that Bases will not until you move those fields into frontmatter.

Which is faster in a large vault?

Bases tends to feel snappier because views are defined once and rendered by the core app. Dataview regenerates its output from the query every time a note containing it opens, which can feel slower in very large vaults or on notes packed with many queries. For most personal vaults the difference is minor.

Will Bases replace Dataview?

Not for power users, at least not yet. Bases covers the common visual database cases with a friendlier builder, and it is the better default for non-coders and mobile use. Dataview still wins on complex logic, calculated fields, inline queries, and anything needing JavaScript. Expect both to coexist rather than one fully replacing the other in 2026.

How do I make my Obsidian tables usable by an AI tool?

A Bases or Dataview table is a view for you to read, not structured context an AI reads on its own, and it goes stale the moment the underlying notes do. If the goal is AI that answers from your real context, you want a layer that distills your notes into current facts and serves them over MCP. That is the model behind a living second brain, explained in prompt packs vs memory packs, and it is what Locul is built to do.

---

If you have spent an afternoon perfecting a Dataview query only to watch the data behind it go stale a week later, the query was never the real problem. Locul builds a second brain from the notes you already keep and keeps it current on its own, then hands that context to your AI tools. It is free to start, 500 memories, local AI, no credit card. See how it works at locul.ai, or check the tiers on the pricing page.