The short answer to Obsidian Tasks versus Dataview is that it is the wrong question, because they do different jobs and the best setup for most people runs both. The Tasks plugin owns task logic: dates, recurrence, priorities, and completing tasks safely. Dataview owns general querying: pulling any structured data in your vault into custom tables and dashboards. You reach for Tasks when the thing you are managing is a task, and Dataview when you want to report across notes in a way the Tasks query language cannot express. Pick one only if you must; pick Tasks, because it is the one that will not quietly break your recurring tasks.
If you are choosing a first task setup, this comparison sits inside the wider Obsidian task management stack, and the Tasks plugin is where almost everyone should start. This piece is about the specific decision between these two, and the one real trap that decides it.
What each plugin is actually for
The confusion comes from the overlap: both can produce a list of your tasks, so they look like competitors. They are not. Tasks is a task engine. Dataview is a query engine that happens to be able to query tasks.
The Tasks plugin understands tasks as first-class things. It knows what a due date is, what recurrence means, that a task has a priority and a status, and it can toggle that status from any view and write it back to the source note correctly. Its query language is built around these task concepts.
Dataview understands your vault as a database. It queries frontmatter, inline fields, links, and file metadata across every note, and assembles the results into tables, lists and calendars. Tasks are just one kind of data it can pull, alongside book ratings, project statuses, meeting notes, or anything else you have tagged with structured fields. Its power is generality; its cost is that it knows nothing special about tasks unless you teach it.
The one difference that decides it
Most differences between the two are matters of taste. One is not, and it should drive the decision if you have any recurring tasks at all. The Tasks documentation states it plainly: Dataview does not understand recurring tasks. If you check off a recurring task from inside a Dataview query, it records a done date but does not generate the next occurrence, so the recurrence silently stops.
This is not a bug you can configure away; it follows from Dataview not modelling tasks as tasks. The practical consequence is a hard rule: never complete a recurring task from a Dataview view. Complete it from the Tasks plugin, or by opening the source note, so the next instance is created. Teams that ignore this discover weeks later that their weekly and monthly routines quietly died the first time someone ticked them off in a dashboard.
The comparison, side by side
Here is the decision laid out on the criteria that actually matter.
| Criterion | Obsidian Tasks | Dataview | Verdict |
|---|---|---|---|
| Understands tasks natively | yes | no, treats them as generic data | Tasks for task logic |
| Recurrence | full support | breaks it on completion | Tasks, decisively |
| Completing tasks safely | writes back correctly | risky for recurring tasks | Tasks |
| Querying non-task data | limited to tasks | anything in the vault | Dataview for reporting |
| Custom dashboards | constrained | highly flexible | Dataview |
| Learning curve | gentle | steeper query language | Tasks to start |
Read it by what you are trying to do. If you are managing tasks, Tasks wins on every task-specific row. If you are building a dashboard that mixes tasks with other vault data, Dataview is the only one that can, as long as you keep completion out of it.
The learning-curve difference
Beyond capability, the two ask different amounts of you, and that shapes which to reach for first. The Tasks plugin is approachable: its create-or-edit command writes the syntax for you, and a useful query is two or three readable lines. You can be productive the day you install it without learning much.
Dataview is more demanding. Its query language, and especially its JavaScript variant, is genuinely powerful but has a real curve, and its documentation is dense enough that people routinely copy queries they do not fully understand. That is fine when the payoff is a dashboard you could not otherwise build, and wasteful when all you wanted was to see your due tasks, which Tasks does with far less effort. The practical implication is that if your need is task management, the lighter tool is also the more capable one for that job, so there is rarely a reason to climb the Dataview curve for tasks alone.
A concrete example of the recurrence trap
It helps to see how the recurrence problem plays out, because it is silent and therefore easy to miss for weeks. Say you keep a recurring task, “water the plants, every 3 days”, and you view your tasks through a Dataview dashboard because it looks tidy. You tick the task off in the dashboard on Monday. Dataview writes a done date. No new instance appears for Thursday, because Dataview has no notion of recurrence to act on. You do not notice, because the task simply vanished as completed, exactly as a one-off task would. Three weeks later you realise the plants have not been on your list since that Monday. The same failure hits weekly reviews, monthly bills and every other repeating commitment routed through a Dataview view. Completing it from the Tasks plugin instead would have created Thursday’s instance automatically. This is why the rule is absolute rather than a preference.
Why running both is the usual answer
For anyone with a real system, the two together beat either alone, which is why the community consistently lands on running both. Let the Tasks plugin own everything about a task’s lifecycle, writing, dating, recurring, completing, and let Dataview assemble the wider picture: a project dashboard that shows tasks alongside note counts, statuses and links. The division of labour is clean because their strengths do not overlap. Tasks is deep on tasks; Dataview is wide across the vault.
What neither of them does, and this is the honest limit of the whole pairing, is decide. Both produce lists, sorted however you ask, and both leave you to read the list and choose where to start. Sorting by priority or due date is not the same as weighing which task matters most given everything around it. That deciding step is a separate layer, and it matters because the cost of choosing wrong is real: with attention already fragmenting, the American Psychological Association puts the price of task switching at up to 40% of productive time, so a morning spent re-reading a long sorted list to pick a start is expensive. The argument for making the deciding step explicit and auditable is in why your task app should explain itself. A tool like ZPXE reads what Tasks and Dataview surface and adds exactly that: a ranking on context, not just fields, with a reason for each position.
A note on performance at scale
One more practical difference shows up only in large vaults, and it is worth knowing before you commit to a Dataview-heavy setup. Because Dataview queries across all your notes’ structured data, complex dashboards can get noticeably slower as a vault grows into the thousands of notes, especially dashboards that mix several queries on one page. The Tasks plugin, narrower in scope, tends to stay snappy because it only ever concerns itself with tasks. This is not a reason to avoid Dataview, its dashboards are worth a little latency, but it is a reason not to route your everyday task views through heavy Dataview queries when a lightweight Tasks query would do. For the thing you look at every morning, the faster, simpler tool is usually the right one.
How to choose for your situation
If you are new to tasks in Obsidian, install only the Tasks plugin and write one query. Do not add Dataview until you hit something Tasks cannot show you, because the second query language is real overhead and most people never need it for tasks alone.
| If you want to | Use | Not |
|---|---|---|
| Set dates, priority and recurrence | Tasks plugin | Dataview |
| Complete a recurring task | Tasks plugin | Dataview, it breaks recurrence |
| Build a cross-note dashboard | Dataview | Tasks alone |
| Report tasks alongside other data | Dataview | Tasks alone |
| Decide what to do first | a ranking layer | either, both only sort |
If you already run Dataview for other things, books, projects, notes, keep it for those and add the Tasks plugin for task logic rather than trying to manage tasks through Dataview. And if your dashboards already mix in tasks, audit them for the recurrence trap today: move any recurring-task completion out of Dataview and into Tasks. Once your capture and presentation are solid across both, the remaining question, which of the surfaced tasks to actually do, is the one a deciding layer answers.
When you do not need Dataview at all
It is worth saying clearly, because Dataview’s power tempts people into installing it prematurely: many excellent task setups never use it. If you do not build cross-note dashboards and you only ever query tasks, the Tasks plugin alone is complete, and adding Dataview is a second query language to learn for no benefit. Dataview earns its place when you genuinely want to report across your vault’s structured data. For pure task management, it is optional, and starting without it is the leaner, more maintainable choice.
Key takeaways: Tasks vs Dataview
Do not treat this as either-or. The Obsidian Tasks plugin is a task engine and the right foundation for task logic, dates, recurrence, priorities and safe completion. Dataview is a query engine for reporting across any vault data, powerful for dashboards but ignorant of tasks as tasks, which is why it breaks recurrence on completion. Use Tasks for tasks, add Dataview only for cross-note reporting, and never complete a recurring task from a Dataview view. And once both are in place presenting your tasks well, remember that presenting is not deciding: a ranking layer like ZPXE is what turns the list they produce into a clear first move.
Quick answers
Is Obsidian Tasks or Dataview better for task management?
Tasks is better for managing tasks; Dataview is better for reporting across your vault, and most people run both. Tasks understands due dates, recurrence, priority and completion natively and writes changes back correctly. Dataview queries any structured data but treats tasks as generic rows, so it is ideal for dashboards and wrong for task logic. Use Tasks for tasks and Dataview only when you need to report across notes in a way Tasks cannot.
Why does Dataview break recurring tasks?
Because Dataview does not model tasks as tasks; it treats a checkbox as a piece of data. When you complete a recurring task from a Dataview query, it records a done date but has no concept of recurrence, so it never generates the next occurrence and the repetition silently stops. The Tasks plugin, which does understand recurrence, creates the next instance on completion. The rule is simple: never tick off a recurring task inside a Dataview view.
Can I use Tasks and Dataview together?
Yes, and it is the usual setup for a real system. Let the Tasks plugin own a task’s whole lifecycle, writing, dating, recurring and completing, and let Dataview assemble wider dashboards that show tasks alongside other vault data like project statuses and links. Their strengths do not overlap, so the division of labour is clean. The one rule when combining them is to keep recurring-task completion inside Tasks, not Dataview.
Do I need both plugins?
Usually not to start. If you only manage tasks, the Tasks plugin alone is complete and Dataview is a second query language to learn for no benefit. Add Dataview only when you genuinely want to report across your vault’s structured data, mixing tasks with notes, statuses and links in one dashboard. Starting with Tasks alone is the leaner, more maintainable choice, and you can add Dataview later the moment a real reporting need appears.
What can neither Tasks nor Dataview do?
Decide. Both produce sorted lists and leave you to read them and choose where to start, but sorting by a single field is not the same as weighing which task matters most given its context. Neither reads how central a task’s note is or how active its project has been, because neither was built to rank on context. A deciding layer like ZPXE adds that: it reads what they surface and returns one ranked list with a reason for each position.
