Real use case for Obsidian: Dataview and Database Folder

A practical Obsidian workflow turns a messy, multi-year crowdfunding backlog into a searchable “Kickstarters I’ve Backed” database—using templates and automation to keep every project note consistent, then Dataview (plus Quick Add, Buttons, and Templater) to generate live tables and status views. The payoff is simple: instead of hunting through emails or spreadsheets for what was funded, what arrived, and what changed after the initial pledge, each project becomes a structured record with clickable links to the latest updates.

The setup starts with a dedicated folder—“Kickstarters I’ve Backed”—so crowdfunding notes don’t clutter the rest of a general knowledge base (where books and other research notes might live). A “Kickstarter template” defines the front matter fields needed for tracking: status, date expected, tier, comments, system (for role-playing games), the Kickstarter link, and shipping address (often “digital”). Templater then automatically applies this template to any new note created inside that folder, removing repetitive manual setup.

To add new projects quickly, Quick Add creates a command that prompts for a project name and generates a new note in the Kickstarter folder using the template. The workflow also adds a “type: Kickstarter” field in front matter so Dataview queries can distinguish real project notes from the database page itself. After creating the first example note (with fields like “awaiting funding” and an expected arrival date), the “Kickstarters I’ve Backed” page is built around Dataview tables.

One Dataview view lists pending items with columns such as status, expected date, ship-to, and a clickable link to each project note. It filters out fulfilled projects so the backlog stays readable. A second view groups items by status using Dataview JS, letting fulfilled and non-fulfilled projects appear in different sections depending on their current state. As the creator’s metadata grows, the template evolves too: pledge manager details lead to tracking both an original expected date and an updated expected date from later announcements, plus fields like tier, amount spent, creator, and an “updates” section where new release notes are recorded.

To keep allowed values consistent, a separate “data model” page defines the statuses the system should use. Since Dataview can’t enforce metadata rules automatically, this reference page acts as a guardrail for consistency (for example, limiting statuses and removing “Backerkit” once it’s no longer part of the tracking model).

For usability, Buttons adds a clickable “Create New Crowdfunding Project” action that triggers the Quick Add command from a UI button rather than relying only on keyboard shortcuts.

Finally, the workflow compares this plugin “stringing” approach with the Database Folder plugin, which can auto-generate a database-style table from a folder. Database Folder can replicate the Dataview table experience with less manual query writing, but it comes with caveats: performance degrades as file counts rise, UI feedback can be clunky when adding items, and embedding/click-through behavior can be wonky. Dataview remains preferred for its atomic, embeddable queries and for the ability to create tailored views per note without being constrained by one shared database configuration.