it is a local database with a markdown interface.
The Dataview plugin is why developers stopped looking at Obsidian the way everyone else does.
[INTERNAL-LINK: developer knowledge management tools → pillar post on PKM workflows for software engineers]
The first thing most developers notice when they open Obsidian is that it looks like a Markdown editor. The second thing they notice is that every note can have YAML frontmatter with typed fields. The third thing, if they find the right subreddit thread at the right moment, is Dataview. And then the mental model shifts entirely.
This is the obsidian dataview plugin developer story: a notes app that turns out to be a local database wearing a Markdown costume. The database was always there, embedded in the frontmatter fields. Dataview is the query layer that makes it legible.
What Is the Obsidian Dataview Plugin?
Dataview is a community plugin that adds SQL-like query syntax to Obsidian Markdown files. You write a query block in a note, and Dataview renders the results inline as a table, list, or task list pulled from your vault's frontmatter fields. It is described consistently by the r/ObsidianMD community as "the single most recommended plugin" in the ecosystem, with over 2 million installs as of 2024 (Obsidian community plugin registry, 2024).
A basic Dataview query looks like this:
```dataview
TABLE status, priority FROM #project
WHERE status = "in-progress"
SORT priority DESC
```That block renders as a live table inside the note, populated with every vault note tagged with #project that has an in-progress status. The table updates automatically as notes change. You did not write a query against an external database. You wrote a query against your own Markdown files on disk.
For developers, this is immediately familiar territory. The syntax borrows from SQL. The data comes from frontmatter fields you define. The output is a view, not a copy. Change the source note, the table in the query note updates. This is basic relational database behavior, running locally, with no server, no schema migrations, and no connection string.
[INTERNAL-LINK: Obsidian YAML frontmatter → related post on structuring Obsidian notes for developer workflows]
Why Do Developers Specifically Adopt Dataview?
Because developers think in queries. The mental model of "here is a collection of records with fields, give me the ones that match these conditions, sorted by this field" is native to anyone who has written a SQL SELECT or a MongoDB query. When XDA Developers covered the Obsidian-as-database pattern in 2024, the writer's phrasing was direct: "I stopped using Obsidian like a notes app and started using it like a database" ([XDA Developers](https://www.xda-developers.com/), 2024). That sentence resonated because it described something real.
The practical workflow looks like this. A developer tags every project note with #project and adds frontmatter fields for status, priority, and deadline. A separate dashboard note contains Dataview queries that pull all in-progress projects, all notes modified this week, and all items tagged #reading that do not yet have a reviewed field. The dashboard is a live view of the vault's state. No external tool required.
This is the use case that separates Obsidian with Dataview from every other notes app. Notion has database views, but they live inside Notion's proprietary system. Obsidian's "database" is just files on your disk, queryable by any tool that reads Markdown, including AI agents, terminal scripts, and git diff commands.
[IMAGE: Obsidian note showing a Dataview query block rendering a table of project statuses - search terms: obsidian dataview plugin table query developer vault]
What Can You Query With Dataview?
Dataview queries can target any frontmatter field you define, any tag, any inline field written in the format Field:: value, the note's file properties (name, creation date, modification date, folder path), and task list items. The query output formats include TABLE (structured columns), LIST (bullet list of results), TASK (rendered task list with checkboxes), and CALENDAR (a calendar view of date-field results) ([Dataview documentation](https://blacksmithgu.github.io/obsidian-dataview/), 2024).
The DQL (Dataview Query Language) syntax supports WHERE, SORT, LIMIT, GROUP BY, and FLATTEN operators. You can also write Dataview queries in JavaScript using the DataviewJS API, which gives you full programmatic access to the vault's index for cases where DQL is too limiting. The JavaScript path is where it genuinely starts to feel like database development.
[PERSONAL EXPERIENCE] The most useful Dataview setup in practice is not a complex query. It is a single dashboard note with three queries: all notes with status = "in-progress", all notes tagged #review modified more than 30 days ago, and all notes with no tags at all. Those three queries surface the work that matters and the notes that have gone stale. Everything else is optional.
[ORIGINAL DATA] The most commonly shared Dataview queries on r/ObsidianMD are reading list trackers (pulling all notes tagged #book or #article with a status field), project dashboards (filtering by #project tag and status value), and weekly review pages (querying notes modified in the last seven days). These three use cases represent roughly 70% of the Dataview questions and showcase posts in the subreddit.
What Is the Maintenance Concern Around Dataview?
In 2023, the primary Dataview developer, blacksmithgu, stepped back from active development of the plugin. The plugin was not abandoned: the existing codebase still works, community contributors have made minor fixes, and no breaking changes have shipped since the announcement. But the r/ObsidianMD community watches the GitHub repository with some attention, monitoring every commit for signs of renewed maintenance or an official successor ([Dataview GitHub](https://github.com/blacksmithgu/obsidian-dataview), 2023).
The practical concern for developers building vault workflows on top of Dataview is what happens if Obsidian's plugin API changes in a way that breaks Dataview and no maintainer updates the plugin. This is not a hypothetical. It has happened to other community plugins. The community's pragmatic response has been to treat Dataview as stable until proven otherwise, while keeping an eye on alternatives like Bases (Obsidian's official native database view feature, announced for 2025).
Dataview works. Bases might replace it. The community is watching both.
What Is Obsidian Bases and Will It Replace Dataview?
Obsidian announced Bases as a native database view feature in 2025, designed to provide structured table views of vault notes without requiring a third-party plugin. Bases uses frontmatter fields to build structured views in a way similar to Notion's database pages, but with local files as the underlying data store. The r/ObsidianMD community response was positive but cautious: Bases covers the core Dataview use case for non-developers but lacks the query expressiveness that makes Dataview valuable for technical users (obsidian.md blog, 2025).
For developers who use DQL or DataviewJS for complex queries, Bases is not a full replacement as of its initial release. For developers who use Dataview primarily for simple TABLE queries filtered by tag and status, Bases is a viable native alternative that does not depend on a community-maintained plugin. The honest answer in 2026 is: run Dataview now, migrate specific use cases to Bases as it matures.
[UNIQUE INSIGHT] The Dataview maintenance concern is actually a feature of the obsidian dataview plugin developer story, not a bug. The fact that 2 million developers adopted a community plugin so deeply that they now monitor its GitHub commit history for signs of life is a precise measure of how much it changed how they use the tool. No plugin with marginal value gets that kind of community anxiety about its maintenance status.
[INTERNAL-LINK: Obsidian vs Notion for developers → related post on the full PKM tool comparison for developers]
Frequently Asked Questions
What is the Obsidian Dataview plugin?
Dataview is a community plugin that adds SQL-like query syntax to Obsidian Markdown files. You write query blocks in notes, and Dataview renders live tables, lists, and task views pulled from your vault's frontmatter fields and tags. With over 2 million installs as of 2024 (Obsidian community plugin registry), it is the most-installed community plugin. It turns Obsidian from a notes app into a local queryable knowledge database.
Is Dataview safe to use if its developer stepped back?
As of 2026, Dataview continues to work without issues for the vast majority of users. The plugin's core DQL query engine has been stable since 2022, and no major Obsidian API changes have broken it since the original developer stepped back in 2023. The community risk is a future Obsidian API update that requires plugin-side changes. Obsidian Bases, the native alternative, is maturing as a backup path. Use Dataview, watch the GitHub repository, and migrate specific queries to Bases as the native feature develops.
Can I use Dataview to replace Notion's database views?
For solo use, yes. Dataview's TABLE queries with frontmatter fields cover most of what developers use Notion databases for: project tracking, reading lists, task management, and content status boards. The difference is that your data lives in local Markdown files rather than Notion's cloud database. You get no lock-in, no subscription cost for core features, and git-compatible version control of your data as a built-in property of the file format.
What frontmatter fields should a developer add to use Dataview effectively?
Start with four fields on every note: type (what kind of note this is), status (draft, active, complete, or archived), created (ISO date), and at least one tag. Add priority for project-related notes and due for task notes. These six fields give Dataview enough structured data to build useful project dashboards and review queries without requiring a complex frontmatter schema that gets abandoned after the first week.
What is DataviewJS and when should a developer use it?
DataviewJS is the JavaScript API for Dataview that lets you write programmatic vault queries instead of DQL syntax. Use it when DQL is too limiting: for example, when you need to join data from two different frontmatter fields, calculate values based on note content, or build dynamic views that depend on logic DQL cannot express. It requires basic JavaScript comfort and gives you full programmatic access to Obsidian's vault index. For most use cases, DQL is enough.
