Obsidian Dataview Guide: Queries, Tables and Tasks

Dataview is the community plugin that turns an Obsidian vault into something you can query. You keep writing ordinary notes, add a few properties at the top of each one, and Dataview builds live lists and tables from them: every project due this month, every book you are reading, every client you have not called in two months. Nothing is copied or exported, so the tables update the moment a note changes. This guide covers the queries you will actually use, with examples taken from the dashboards in our own vaults.

What the Obsidian Dataview Plugin Does

Dataview reads three kinds of data from your notes. Properties are the YAML block at the top of a note, between two lines of three dashes. Inline fields are written in the body as key:: value, or inside square brackets on a task line. Implicit fields are the ones Obsidian already knows, such as file.name, file.ctime, file.tags and file.link. A query is a code block whose language is dataview, and in reading view it renders as a list, a table, a task list or a calendar. A note with properties looks like this:

---
status: active
due: 2026-11-27
owner: Lina
---
# Website redesign

Install the Dataview Plugin and Write Your First Query

Open Settings, then Community plugins, turn off restricted mode if it is still on, choose Browse and search for Dataview. Install it, enable it, and you are done: there is nothing to configure before the first query. Create a note, add a code block with the language dataview, and start with the simplest query there is, a list of every note in a folder:

```dataview
LIST
FROM "Projects"
```

Switch to reading view and the block becomes a list of links. Change LIST to TABLE and name the properties you want as columns, and you have a project tracker:

```dataview
TABLE status, due, owner
FROM "Projects"
WHERE status = "active"
SORT due ASC
```

Dataview Query Syntax: FROM, WHERE, SORT and GROUP BY

Every query starts with its type, LIST, TABLE, TASK or CALENDAR, followed by optional commands that run in order. FROM chooses the source: a folder in quotes, a tag such as #book, or [[]] for notes that link to the current one, and sources combine with AND, OR and a leading minus to exclude. WHERE keeps only the rows that match, for example WHERE status = "active" or WHERE due <= date(today). SORT orders by one or more fields, ascending or descending, and LIMIT cuts the result to a number of rows.

GROUP BY is where tables get useful. It collects rows that share a value into one row per group, and the original notes become a list called rows, which you can count with length(rows) or add up with sum(rows.value). The group value itself is called key. This query counts projects by status:

```dataview
TABLE rows.file.link AS "Notes", length(rows) AS "Count"
FROM "Projects"
GROUP BY status
```

Two details trip up most people. A property name with a hyphen would be read as a subtraction, so it has to be written as row["date-started"], which is how our book notes vault reads its reading dates. A name with capitals or spaces, such as "Due Date", is also available in lower case with a hyphen, as row["due-date"]. And WITHOUT ID after TABLE hides the automatic first column of file names when you want to choose the first column yourself.

Obsidian Dataview Tasks: Querying Checkboxes Across the Vault

A TASK query returns the checkboxes themselves, not the notes, and you can tick them off directly in the results. Dataview reads a due date written as an inline field on the task line, and it also understands the 📅 date written by the Tasks plugin:

- [ ] Send the revised quote [due:: 2026-10-28]

```dataview
TASK
FROM "Projects"
WHERE !completed AND due AND due <= date(today)
GROUP BY file.link
```

If tasks are the centre of your system, the Tasks plugin has the richer task syntax and recurrence, and our guide to Obsidian tasks compares the two. Dataview is the better choice when tasks are one part of a dashboard that also shows notes and properties.

Dataview Table Examples from Our Vaults

Every query below is running in a vault you can download, so you can open it and see the result on real data. The project management vault lists active projects sorted by due date. The D&D campaign vault groups every NPC by location on its DM screen with GROUP BY location. The book notes vault shows what you are reading now and what you finished, with ratings. The student vault lists coursework due from today onwards with WHERE due AND due >= date(today). Our Obsidian CRM template goes furthest: follow-ups due this week, pipeline value by stage and contacts you have not spoken to in 60 days, using date(today) - last_contact > dur(60 days).

Obsidian Dataview vs Bases

Bases is a core plugin added to Obsidian in 2025. It also turns properties into tables, but you build the view by clicking instead of writing a query, and you can edit property values directly in the table. A base is saved as a .base file and its definition is readable YAML:

filters:
  and:
    - file.inFolder("Projects")
views:
  - type: table
    name: All
    groupBy:
      property: status
      direction: ASC

Use Bases when you want an editable, spreadsheet-like view of notes and their properties, with no plugin to install. Keep Dataview for what Bases does not do: queries embedded in the middle of a note, task queries, links between notes as a source, date arithmetic such as "not touched in 60 days", and JavaScript queries through DataviewJS. Many vaults use both, and the CRM vault ships a Bases pipeline next to its Dataview dashboard so you can compare them on the same data.

Why a Dataview Query Shows No Results

Most empty tables come down to four causes. The folder in FROM does not match the real path, which is case sensitive and needs the full path for subfolders. A date was typed in a format Dataview does not read as a date, such as 10/28/2026, so comparisons with date(today) never match; write dates as YYYY-MM-DD. A text value was compared with different capitals or spaces, because "Active" and "active" are different values. Or you are still in editing view, where the query appears as code. If the date shown in your tables looks wrong, Dataview's settings have a date format field that uses Luxon tokens, so the year is written yyyy there rather than YYYY.