Notion database views in Obsidian Projects plugin

Obsidian Projects is built to make “Notion-style” database views possible inside Obsidian without forcing users to rewrite their notes for every visualization. The core idea is a unified data format: Projects parses note metadata once, then feeds the same structured dataset to multiple views—table, board, calendar, and gallery—so switching perspectives doesn’t require duplicating notes or reconfiguring front matter for each plugin.

The need behind Projects comes from content workflows. Nicole van der Hoeven describes tracking multiple recurring deliverables—blog posts, scripts, drafts—where each item has a status and a due date. Traditional approaches in Obsidian can work, but calendar and board plugins often require their own specific front matter properties, and interoperability is inconsistent. That leads to copying content, maintaining multiple versions of the same note, or being stuck with one view type instead of moving fluidly between board, calendar, and table.

Projects addresses that by separating “querying” from “presentation.” The querying layer pulls in notes from chosen folders (optionally including subfolders), filters them, and parses their fields into a record-based dataset. The views then focus on rendering: a table view exposes structured fields like status, dates, and booleans; a board view groups items by a chosen YAML property; a calendar view places items using extracted date fields and can display additional properties as checkboxes; and a gallery view renders items in a grid based on an image field. In the demo, a single set of YAML front matter drives all four views, and edits in one view stay synchronized with the others.

A key design constraint is “Leave No Trace.” Projects aims not to clutter markdown notes with plugin-specific configuration. Instead, configuration lives in the Projects plugin, while the notes remain plain markdown with front matter that already matches established patterns. The plugin also aims to be a data provider rather than a competitor to other view plugins. The ambition is to let other plugins register themselves as custom views so they can reuse Projects’ parsed dataset without re-implementing indexing, filtering, and event handling.

The live walkthrough shows how Projects can plug into existing DataView workflows. By pasting a DataView query into a new project, the dataset can be reshaped using DataView’s field selection and aliasing, and the Projects views adapt to the resulting fields. There’s a tradeoff: when fields are aliased through DataView, Projects may not know the original property names, which limits editing back into the source notes.

Beyond content calendars, participants explore broader use cases: RPG campaign management, session tracking, and visualizing cover art or character images through the gallery view. Questions from the community focus on drag-and-drop limitations (sorting cards isn’t fully supported yet), future filtering UI, and whether tasks or richer field types can be supported. The roadmap emphasizes better filtering before data reaches views, tighter integration with other Obsidian database-like tools, and expanding the view ecosystem—so users can keep their notes clean while gaining database-style navigation across multiple representations.