Obsidian Dataview: The Complete Guide to Dynamic Dashboards and Queries (2026)

The true power of Obsidian isn't the notes you write — it's what happens when those notes start talking to each other. Dataview is the plugin that flips the switch. It turns your vault from a pile of static markdown files into a living database you can query, sort, and summarize on demand. Tag a note, add a due date, set a project status, and Dataview assembles that information into tables, lists, and dashboards that update themselves every time you change something.

If you've ever scrolled through a dozen folders hunting for "all my active projects" or "every task I still owe someone," you already understand the problem Dataview solves. Instead of maintaining index notes by hand, you write a short query once and let the plugin keep it current forever. Your reading log, your task board, your weekly review — all of it can become automatic.

Here's what we'll cover: what Dataview actually is, how to install it, how to add the metadata it reads, the four query types, how to choose and filter your sources, inline queries, two complete copy-paste dashboards, and a troubleshooting checklist for when a query stubbornly returns nothing. By the end you'll be able to build your own dashboards — or skip the DQL entirely and let a ready-made template do it for you.

What Is Obsidian Dataview, and Why Does It Matter?

Dataview is a live index of your vault plus a query language that reads the metadata in your notes and renders it as tables, lists, task boards, or calendars. You don't move or duplicate any data. You describe what you want — "every note in Projects tagged active, sorted by due date" — and Dataview builds the view, refreshing it automatically as your vault changes.

That matters because manual indexes rot the moment you create them. A hand-written "Active Projects" note is out of date the next time you finish a project. A Dataview query never is. The payoff compounds as your vault grows: the same three-line query that shows two projects today will show twenty next year, with zero extra effort from you.

Think of every note as a row in a database and every property as a column. Dataview lets you ask questions of that database in plain, readable syntax. This is the natural companion to good linking habits — if you're still building those, our complete guide to connecting your notes pairs perfectly with what you'll learn here, because the more your notes reference each other, the more Dataview has to work with.

How Do You Install and Enable Dataview?

You install Dataview through Obsidian's Community Plugins panel in under a minute. Here's the exact sequence:

1. Open Settings → Community Plugins.
2. If you see "Restricted mode" or "Safe mode" enabled, turn it off (this lets community plugins run).
3. Click Browse, then search for Dataview.
4. Click Install, then Enable.

Once enabled, Dataview begins indexing your vault in the background. On a small vault this is instant; on a large one it may take a few seconds the first time.

Next, open the plugin's settings and check two toggles that unlock its full capability:

• Enable Inline Queries — lets you surface a single value mid-sentence (covered later).
• Enable JavaScript Queries — required only if you plan to use DataviewJS for advanced custom logic. Leave it off if you're starting out.

Tip: You don't need to "rebuild" anything manually. Dataview re-indexes automatically as you edit, create, and delete notes. The one exception is covered in the troubleshooting section near the end.

How Do You Add Metadata: Frontmatter Properties vs Inline Fields?

Dataview reads two kinds of metadata: YAML frontmatter (Obsidian calls these Properties) and inline fields written in the body of a note. Both become queryable columns; you choose based on where the data naturally lives.

Frontmatter (Properties) sits at the very top of a note between two --- lines and is best for structured, note-level data:

---
status: active
due: 2026-07-15
priority: 1
tags: [project, client]
---

Inline fields let you record data mid-note using a double colon. Use key:: value on its own line, or [key:: value] to embed a field inside a sentence:

Project kicked off today.
status:: in-progress
Budget is [budget:: 4500] for this quarter.

Field types are inferred automatically: text, number, date (ISO format like 2026-07-15), list (tags: [a, b]), and link ([[Some Note]]). On top of whatever you add, every note ships with built-in file.* fields you can query without defining anything:

Built-in field	What it returns
file.name	The note's filename
file.link	A clickable link to the note
file.ctime / file.mtime	Created / last-modified time
file.tags	All tags in the note
file.inlinks / file.outlinks	Notes linking in / out
file.folder	The folder path

That file.inlinks field is a quiet superpower — it lets you build views based purely on how your notes connect, which is exactly why deliberate linking pays off.

What Are the Four Query Types: TABLE, LIST, TASK, and CALENDAR?

Dataview offers four query types, and each produces a different shape of output. You write them inside a code fence labelled dataview.

LIST is the simplest — a bulleted list of notes:

LIST
FROM "Projects"
WHERE status = "active"

TABLE is the everyday workhorse, adding columns for any field you name:

TABLE status, due, file.mtime AS "Last Edited"
FROM "Projects"
SORT due ASC

TASK pulls individual checkbox items (- [ ]) from your notes, grouped by the note they live in — perfect for a vault-wide to-do view:

TASK
WHERE !completed

CALENDAR plots notes onto a month grid using a date field you choose, which is handy for visualizing meetings or deadlines:

CALENDAR due
FROM "Projects"

Reach for LIST and TABLE for almost everything, TASK when you want checkboxes aggregated across notes, and CALENDAR when a date-on-a-grid view tells the story better than rows. If task management is your main goal, our complete guide to task management in Obsidian shows how these query types fit a real workflow.

How Do You Choose Your Sources with FROM?

The FROM clause tells Dataview which notes to consider, and you can target folders, tags, or links. Get this right and your queries stay fast and focused.

• By folder: FROM "Projects" (always quote the path; use "Areas/Health" for subfolders).
• By tag: FROM #active (no quotes on tags).
• By incoming link: FROM [[Project Alpha]] finds every note that links to that note.
• By outgoing link: FROM outgoing([[Project Alpha]]) finds notes that Alpha links to.

Combine sources with AND and OR, and exclude with a minus sign. This is the single most useful pattern in practice — pull a folder, narrow by tag, and drop your templates:

TABLE status, due
FROM "Projects" AND #active AND -"Templates"
SORT due ASC

That query reads everything in the Projects folder tagged #active while excluding anything in the Templates folder.

Note: Scoping with FROM isn't just tidy — it's a performance habit. A query that starts FROM "Projects" scans only that folder, while one with no FROM scans your entire vault every refresh.

How Do You Filter, Sort, and Group Results?

Once you've chosen your source, WHERE, SORT, and GROUP BY shape the output. These are the clauses you'll tune most often.

WHERE filters rows using comparisons and functions:

• Comparisons: WHERE priority >= 2, WHERE status = "active", WHERE due < date(today).
• Functions: contains(file.name, "2026"), length(tags) > 0, and date math like due <= date(today) + dur(7 days).

SORT orders results: SORT due ASC or SORT file.mtime DESC. LIMIT caps the count: LIMIT 10.

GROUP BY collapses results under a shared value — group tasks by status, notes by folder, or reading by author:

TABLE rows.file.link AS "Projects"
FROM "Projects"
GROUP BY status

When a field holds a list (like multiple tags or authors), use FLATTEN to unroll it into one row per value before grouping — otherwise the list is treated as a single clump. Here's a copy-paste "recently modified notes" recipe that combines several of these clauses:

TABLE file.mtime AS "Modified"
FROM ""
SORT file.mtime DESC
LIMIT 10

And an "untagged notes" cleanup query, useful for keeping a tidy vault:

LIST
WHERE length(file.tags) = 0

How Do You Write Inline DQL, and When Should You Use DataviewJS?

Inline DQL lets you drop a single computed value directly into a sentence, instead of rendering a whole block. You write it with a backtick-equals prefix. For example, = this.due prints the current note's due date inline, and = dv.current().file.mtime prints when this note was last edited — both update live.

This is ideal inside templates and daily notes: a header that reads "Last reviewed: = this.reviewed" stays accurate without you touching it. Inline queries must be enabled in settings (you toggled this during install).

DataviewJS is the advanced tier. It swaps the readable DQL syntax for JavaScript and the dv.* API, giving you loops, conditionals, and arbitrary custom logic — for example, dv.pages("#book").where(p => p.rating > 4). The trade-off is a steeper learning curve and the JavaScript Queries toggle. Treat it as the next step after you're comfortable with DQL, not your starting point. The vast majority of dashboards never need it.

Tip: If you find yourself reaching for DataviewJS to do something simple, there's usually a plain-DQL way. Save the JavaScript for genuinely custom rendering.

How Do You Build Real Dashboards for Tasks and Projects?

A dashboard is just a note holding several queries that together answer "what needs my attention?" Here are two complete, copy-paste examples you can drop into a note and edit.

Walkthrough 1 — a task dashboard. This surfaces every open task across your vault, isolates the overdue ones, and groups them by file so you can see what each project owes:

TASK
WHERE !completed AND due AND due < date(today)
GROUP BY file.link

Swap due < date(today) for due <= date(today) + dur(7 days) to see everything due this week instead. For richer due-date and recurrence handling, pair Dataview with the Tasks plugin: Tasks owns scheduling, recurrence, and the slick checkbox UI, while Dataview aggregates and reports across notes. Our ultimate guide to the Tasks plugin covers that pairing in full, and it slots neatly into a GTD setup if that's your method.

Walkthrough 2 — a projects dashboard. A single table of active projects with status, the next action, and when each was last touched:

TABLE status AS "Status", next_action AS "Next Action", file.mtime AS "Last Modified"
FROM "Projects" AND -"Templates"
WHERE status != "done"
SORT file.mtime DESC

Building these from scratch is a great way to learn — but if you'd rather have them already wired up, this is exactly where a ready-made template shines. Obsibrain ships Dataview-powered dashboards for tasks, projects, and daily/weekly reviews preconfigured out of the box, so you get the payoff without writing a line of DQL.

What Are the Common Errors and Performance Pitfalls?

Most "broken" Dataview queries fail for the same handful of reasons. Run through this checklist before assuming the plugin is at fault.

• Inline field syntax: use a double colon (status:: active), not a single one. A single colon does nothing outside frontmatter.
• Case sensitivity: Status and status are different fields, and "Active" won't match "active" in a WHERE. Stay consistent.
• Quote your folder paths: FROM "Projects" works; FROM Projects is read as a tag-like source and fails.
• Missing fields return null: a query that filters on priority silently drops every note that lacks a priority field. That's often why results look incomplete rather than empty.
• Don't mix field types: if due is a date in some notes and plain text in others, comparisons and sorting break. Keep a field one type vault-wide.

For performance on large vaults, the rule is to give Dataview less to scan:

1. Scope every query with FROM "Folder" or FROM #tag instead of FROM "".
2. Add a LIMIT to long lists you don't fully read.
3. Avoid putting heavy DataviewJS in notes you open constantly.
4. If results look stale after edits, toggle the plugin off and on in settings (or restart Obsidian) to force a re-index.

Note: A query returning nothing is far more often a metadata problem (a missing field, a typo'd folder name, a case mismatch) than a Dataview bug. Start with the field, not the syntax.

Dataview vs Obsidian Bases: Which Should You Use in 2026?

Obsidian shipped Bases as a core feature in 2025, and it overlaps with Dataview enough that the choice now confuses newcomers. Bases is a no-code, spreadsheet-style database view: you build tables and filters through a GUI, it's built into Obsidian (no plugin), and it works smoothly on mobile. Dataview is a text-based query language: more expressive, more portable as plain markdown, and far better at pulling tasks and computing derived values.

Use Bases when you want a quick visual table with no syntax to learn and you live on mobile. Reach for Dataview when you need TASK queries, inline values inside prose, complex filtering, or dashboards that travel as plain text. Many power users run both — Bases for browsable databases, Dataview for reporting and task aggregation. Neither is going away, so pick per use case rather than committing to one.

Frequently Asked Questions

Is the Dataview plugin free, and is it still maintained and safe to rely on in 2026? Yes. Dataview is free, open-source, and one of the most-installed community plugins in the Obsidian ecosystem. It's stable and widely depended upon. That said, it's a community plugin (not core), so for mission-critical setups it's wise to keep your data as plain markdown — which Dataview does by design, since it only reads your notes and never alters them.

What's the difference between Dataview and the Tasks plugin — do I need both? They solve different problems and pair well. The Tasks plugin manages individual tasks: due dates, recurrence, scheduling, and a polished checkbox interface. Dataview aggregates and reports — building tables and lists across your whole vault. For serious task management most people run both, letting Tasks handle the task lifecycle while Dataview powers the dashboards.

Why is my Dataview query not working or showing no results? Ninety percent of the time it's the metadata, not the query. Check for a single instead of double colon on inline fields, a case mismatch (Status vs status), an unquoted folder path, or a field that simply doesn't exist on the notes you expected. A WHERE clause filtering on a missing field silently removes those notes. Fix the field first, the syntax second.

Does Dataview slow Obsidian down on large vaults, and do queries work on mobile and Obsidian Publish? On very large vaults, unscoped queries can lag — solve it by adding a FROM folder/tag and a LIMIT. Queries run on mobile (though heavy ones are slower on phones) and sync across devices as plain text since they live inside your notes. Note that Dataview does not render on Obsidian Publish, so published pages show the raw query, not the table.

Start Small and Let It Grow

You don't need to master every clause this week. Add a status property to a few project notes, paste in the recently-modified table, and watch it populate — that single win is usually enough to make the system click. From there, build a task dashboard, then a projects view, then a weekly review, adding one query at a time as a real need appears.

And if you love the results but not the upkeep, you don't have to build any of it yourself. Obsibrain ships these Dataview dashboards preconfigured — tasks, projects, and periodic reviews ready on day one — so you can spend your time thinking instead of writing queries. Whether you build it or drop it in, the goal is the same: a vault that organizes itself while you focus on the work that matters.