Obsidian Bases - Comprehensive guide

The Architect's Guide to Obsidian Bases: Building a Unified Knowledge Management System

Part I: the Obsidian Database Philosophy: a New Mental Model

The transition to Obsidian's 'Bases' feature from platforms like Notion or Airtable requires a fundamental shift in perspective. These applications, while powerful, are built on a paradigm of structured, isolated containers. In contrast, Obsidian Bases operates on a principle of fluid, vault-wide querying. Understanding this distinction is the first and most critical step in architecting a robust, personalized, and enduring knowledge management system. This section establishes the core philosophy that will inform every subsequent structural decision, moving from the conceptual model of data interaction to the practical anatomy of an individual note.

Section 1.1: From Silos to Synthesis: why Bases Aren't Databases

The most common point of confusion when approaching Obsidian Bases is the term "database" itself. In the context of applications like Notion or Airtable, a database is a discrete, self-contained table or "base".1 One creates a "Books" database, and it contains only books. A "Projects" database contains only projects. Each entry is a record added to that specific container, and the data lives
inside that silo.3
Obsidian fundamentally inverts this model. An Obsidian vault is not a collection of databases; the entire vault is the database.4 The 'Bases' feature does not create containers for data. Instead, it provides a powerful query engine to create dynamic, filtered "views" of all the notes that already exist across the entire vault.5 A more accurate mental model is to think of a
.base file not as a database, but as a "vault views container".7
This architectural distinction is not a limitation; it is the system's core strength. In a siloed model, seeing connections across different data types requires building explicit, often complex, "relations" or "linked records".8 To see all science fiction content, one would need to link the "Sci-Fi" entry in a "Genres" table to individual records in the "Books" table, the "Movies" table, and the "Games" table.
In Obsidian, this cross-contextual analysis is native. Because every Base queries the entire vault by default, a single view can be configured to show any note that meets the specified criteria, regardless of its "type" or folder location. For instance, a single view within a Culture.base file can effortlessly display all notes where the genre property contains "Sci-Fi." This query will automatically pull in notes with type: Book, type: Movie, and type: Show without any need for pre-defined relationships between them.7 The system is inherently designed for synthesis and the discovery of emergent connections, rather than the mere cataloging of isolated items. This allows for the creation of dashboards that reflect holistic concepts—like "everything I'm currently consuming" or "all active projects and their related research"—in a way that is far more fluid and integrated than silo-based architectures allow.

Section 1.2: The Anatomy of an Atomic Note: Your Data's Single Source of Truth

With the vault itself established as the database, the individual Markdown file becomes the fundamental record or "atomic note." All the structured, queryable data that Bases relies upon lives exclusively within the YAML frontmatter section at the very top of each file.10 This section, delineated by
--- at the beginning and end, is where "Properties" are defined.
It is critical to understand that, by design, Obsidian Bases do not read, parse, or query the main content of a note.12 This means that inline data fields popularised by the Dataview community plugin (e.g.,
Rating:: 5) are invisible to the Bases engine.13 This constraint is not an oversight but a deliberate performance and design choice. It necessitates a disciplined and consistent approach to metadata management: if data needs to be sorted, filtered, or displayed in a Base, it
must exist as a formal property in the YAML frontmatter.
This leads to a powerful "Structured/Unstructured Symbiosis" that distinguishes the Obsidian paradigm from more uniformly structured tools like Notion, where every piece of content is a manipulable "block".1 In an Obsidian note architected for Bases, a clear division of labor emerges:

This symbiotic relationship offers the best of both worlds. The structured properties provide the robust framework needed for sophisticated data management, allowing for the creation of powerful organizational views that rival those in Airtable or Notion. Simultaneously, the unstructured body preserves the creative freedom and serendipitous linking that is the hallmark of a true second brain. One can manage a project with the rigor of a database while exploring the ideas within it with the freedom of a writer's notebook, all within a single file.

Part Ii: Architectural Blueprint: Structuring Your Unified Vault

Moving from philosophy to practice, this section provides the architectural blueprint for a scalable and coherent Obsidian vault. A well-designed system is not merely a collection of notes but a carefully planned environment that minimizes friction and maximizes clarity. This involves making a strategic decision on how to organize the .base files themselves, establishing a universal data language through a core property schema, and implementing the necessary scaffolding of folders and templates to ensure long-term consistency and ease of use.

Section 2.1: The Monolithic vs. the Modular Approach: Designing Your Base Strategy

The "vault view container" model of Bases presents a primary architectural choice in how to organize the .base files that generate these views.7 There are two main approaches:

For the specified use cases, a Hybrid "Container" Approach is the most effective and elegant solution. This strategy leverages the strengths of both models:

  1. Group related items into containers: Create a Media.base to house all consumption-related views (Books, Movies, Shows, Music). Create an Aspirations.base for Bucket Lists and Wishlists. This aligns the digital structure with the user's mental models, recognizing that these items are often facets of a single broader activity (e.g., "entertainment" or "goals"). This also allows for powerful, cross-cutting views within a single Base, such as a "Master To-Do List" that shows books to read and movies to watch.
  2. Isolate functionally distinct items: Keep categories with unique properties and workflows in their own atomic bases. Recipes.base and Projects.base are prime examples. Their data models and the actions one takes with them are sufficiently different from other categories to warrant their own dedicated .base files.

This hybrid architecture provides the optimal balance. It minimizes filter redundancy and simplifies management for related data, while maintaining the logical separation needed for distinct workflows. The structure of the .base files becomes a direct reflection of the user's cognitive map, reducing the mental load required to navigate and manage the system.

Section 2.2: The Universal Data Language: a Core Property Schema for Your Vault

The flexibility of Obsidian's property system is also its greatest challenge. Without a predefined schema, inconsistencies are inevitable (rating vs. Score, due_date vs. deadline), which will break filters and undermine the integrity of the entire system. Establishing a consistent, vault-wide "Universal Data Language" through a master property schema is therefore not optional; it is the foundation upon which the entire structure rests.
The cornerstone of this schema is a mandatory type property for every note intended for use with Bases. This single property acts as the primary identifier, allowing each Base to filter for its relevant data. For example, the Media.base will have a global filter that looks for notes where type is "Book," "Movie," "Show," or "Music." This simple rule prevents data cross-contamination and ensures that views are clean and accurate.
Building on this foundation, a master schema should define all properties used across the vault, specifying their name, data type, the note types they apply to, and any allowed values. This document becomes the single source of truth for the vault's data model.
Table 1: Master Property Schema

Property Name Data Type Applies to 'type' Description & Allowed Values
type Text All The primary identifier for the note's category. (Values: 'Book', 'Movie', 'Show', 'Music', 'Recipe', 'Project', 'Query', 'BucketListItem', 'WishlistItem')
status Text All Tracks the lifecycle stage of an item. (Values: 'Backlog', 'In Progress', 'Done', 'On Hold', 'Archived')
rating Number Book, Movie, Show, Music, Recipe A personal rating, typically on a 1-5 scale.
tags List All Keywords for thematic organization and discovery. (e.g., ``)
created_date Date All The date the note/item was created, automatically managed by Obsidian.
cover_image Text Book, Movie, Show, Music A URL or wikilink to a cover image for use in Card views.
consumed_date Date Book, Movie, Show, Music The date the item was finished/consumed.
author List Book The author(s) of the book.
director List Movie, Show The director(s) of the film or series.
artist List Music The primary artist(s) for the album or track.
release_year Number Book, Movie, Show, Music The year the media was originally released.
genre List Book, Movie, Show, Music The genre(s) associated with the media.
cuisine Text Recipe The type of cuisine (e.g., 'Italian', 'Mexican').
prep_time Number Recipe Preparation time in minutes.
cook_time Number Recipe Cooking time in minutes.
servings Number Recipe The number of servings the recipe yields.
source_url Text Recipe, Query A URL to the original source.
photo Text Recipe A wikilink to a local image of the finished dish.
project_status Text Project A more detailed status for projects. (Values: 'Active', 'Planning', 'Completed', 'Backburner')
due_date Date Project The target completion date for the project.
priority Text Project The priority level of the project. (Values: 'High', 'Medium', 'Low')
related_notes List Project, Query Wikilinks to other relevant notes in the vault.
query_status Text Query The status of a research question. (Values: 'Open', 'Answered', 'Pending')
question Text Query The specific question being investigated.
item_type Text BucketListItem, WishlistItem Differentiates between bucket list and wishlist items.
cost Number WishlistItem The estimated cost of the item.
urgency Text WishlistItem How soon the item is desired. (Values: 'High', 'Medium', 'Low')
link_to_buy Text WishlistItem A URL to a product page.
achieved Checkbox BucketListItem, WishlistItem A true/false value indicating if the item has been completed or acquired.

Section 2.3: Scaffolding for Success: Integrating Folders and Templates

While Bases operate primarily on properties rather than file location, a minimal and logical folder structure provides essential organizational scaffolding and prevents the vault from becoming a chaotic flat list of files. This structure should support the workflow, not dictate it. A recommended minimal setup is:

The true power of this architecture is realized through automation. The Master Property Schema must be enforced to maintain data integrity, and the most effective way to do this is with templates. Using a community plugin like Templater, one can create a template for each note type. When a user triggers the creation of a "New Book Note," for example, the Templater plugin will create a new file and automatically insert the complete YAML frontmatter block with type: Book and all other relevant properties from the schema, pre-filled with placeholders.
For example, a Tpl-Book.md template file would contain:

YAML

---
type: Book
status: Backlog
rating:
tags:
- book
cover_image:
consumed_date:
author:
release_year:
genre:
created_date: {{date:YYYY-MM-DD}}
---

# {{title}}

## Summary

## Key Takeaways

## Quotes

This simple automation transforms the process of data entry. It eliminates the risk of typos in property names, ensures every required field is present, and dramatically lowers the friction of creating new, well-structured notes. The templates become the practical enforcement mechanism for the entire data architecture, ensuring the system remains robust and reliable over time.

Part Iii: Implementation Masterclass: Building Your Personal Dashboards

This section translates the architectural blueprint into a series of concrete, actionable implementations. Each of the nine specified categories will be addressed with a detailed guide covering its specific property schema, the setup of its corresponding Base, and the configuration of multiple views designed for different workflows. These examples provide not only copy-paste-ready code but also illustrate the practical application of the principles established in the preceding sections.

Section 3.1: The Media Console (Books, Movies, Shows, Music)

This "Container" Base will serve as a central hub for managing all consumed and to-be-consumed media, leveraging the shared properties of these categories for powerful, unified views.

Property Schema

The following properties from the Master Schema are essential for the Media Console:

Base Setup (Media.base)

Create a new file named Media.base inside the 00-System/ folder. This Base will use a global filter to ensure it only pulls in notes corresponding to the four media types. This is a foundational step that prevents unrelated notes (like Projects or Recipes) from appearing in any of the media views.
The core syntax for the .base file, which can be edited by clicking the "code" button in the advanced filter editor, will be as follows:

YAML

filters:
or:
- type == "Book"
- type == "Movie"
- type == "Show"
- type == "Music"
views:
- type: table
name: Master List
# View-specific configurations will be added below

View Configurations

Within this single Media.base file, multiple views can be created to serve different purposes.

View 1: To Consume (Kanban Board)

This view provides an at-a-glance status of all media currently in the pipeline, mimicking a Trello or Notion board.

This view acts as a visual trophy case, showcasing all media that has been completed.

View 3: Master Table (Data View)

This view is the power-user tool for detailed analysis, sorting, and filtering across the entire media collection.

View 4: Recent Sci-fi (Advanced Filter Example)

This demonstrates combining the global filter with a specific, view-level filter for a niche interest.

Section 3.2: The Digital Kitchen (Recipes)

This atomic Base is designed for managing a personal recipe collection, with a focus on visual browsing and practical filtering for meal planning.

Property Schema
Base Setup (Recipes.base)

Create a new file Recipes.base in the 00-System/ folder with a simple global filter.

YAML

filters:
- type == "Recipe"
views:
- type: table
name: All Recipes

View Configurations

This view provides a beautiful, cookbook-style visual grid of all available recipes.

View 2: Quick Meals (Functional Table)

This view is a practical tool for busy days, instantly showing recipes that can be made in 30 minutes or less.

Section 3.3: The Project Command Center (Projects)

This Base is the central nervous system for all personal and professional projects, designed to track progress, deadlines, and priorities.

Property Schema
Base Setup (Projects.base)

Create Projects.base in 00-System/ with the global filter:

YAML

filters:
- type == "Project"
views:
- type: table
name: Active Projects

View Configurations
View 1: Active Projects (Action Dashboard)

This is the primary daily-driver view, showing what needs immediate attention.

View 2: Planning Board (Priority Matrix)

This view helps in strategic planning by visualizing projects based on their priority.

A key workflow adaptation from platforms like Airtable is necessary here. Airtable and Notion use formal "relation" properties to create machine-readable links between different databases.9 Obsidian Bases, operating on plain text, lacks this native capability. However, this can be effectively simulated by leveraging Obsidian's core strength: the wikilink. By defining the
related_notes property as a List type, one can embed direct wikilinks to other notes within the project's frontmatter (e.g., related_notes:]", "]"]). The Base view will render these as live, clickable links. While this does not allow for automated roll-ups or lookups (e.g., automatically pulling the status of a related query into the project view), it provides immediate, one-click navigation to all relevant context. This creates a functional, albeit manual, relational system that is perfectly suited to a personal knowledge management context.

Section 3.4: The Inquiry Hub (Queries)

This Base serves as a log for questions, ideas to research, and problems to solve. It is a simple but essential tool for intellectual curiosity and project research.

Property Schema
Base Setup (Queries.base)

Create Queries.base in 00-System/ with the global filter:

YAML

filters:
- type == "Query"
views:
- type: table
name: Open Questions

View Configurations
View 1: Open Questions

A straightforward list of all unresolved inquiries.

Section 3.5: The Aspiration Atlas (Bucket Lists & Wishlists)

This "Container" Base consolidates all long-term goals and desired items into a single management hub, separating them into logical views for clarity.

Property Schema
Base Setup (Aspirations.base)

Create Aspirations.base in 00-System/ with a global filter to include both types.

YAML

filters:
or:
- type == "BucketListItem"
- type == "WishlistItem"
views:
- type: table
name: Bucket List

View Configurations
View 1: Bucket List

A view focused on life goals and experiences yet to be achieved.

View 2: Wishlist

A practical, sortable list of items to acquire.

View 3: Accomplished

A celebratory view of all completed goals and acquired items, demonstrating the use of file properties for sorting.5

Part Iv: Advanced Techniques and System Maintenance

With the core architecture and individual dashboards in place, this final section elevates the system from a static collection of lists to a dynamic, interconnected, and sustainable knowledge environment. These advanced techniques leverage the unique capabilities of Obsidian to create contextual views and automated indexes, while the maintenance strategies ensure the system's long-term health and integrity.

Section 4.1: Mastering Dynamic Queries and Contextual Views

One of the most powerful, yet often overlooked, features of Obsidian Bases is the ability to create filters that are relative to the note in which the Base is embedded. This is achieved through the this.file object, which refers to the properties of the host note itself.5 This allows for the creation of highly contextual, self-updating dashboards that are far more dynamic than a static
.base file.
Consider a scenario where each key collaborator has their own note (e.g., John Doe.md). The frontmatter of this note might include person_name: "John Doe". By embedding the Projects.base directly into the body of the John Doe.md note and applying a specific filter, one can create a view that shows only the projects associated with him.
The embedded Base code block would look like this:
`base
views:

When this code is placed inside John Doe.md, it dynamically generates a table of all projects where "]" is listed in the related_notes property. This transforms a simple contact note into a comprehensive dashboard for that relationship. The same principle can be applied to project notes to show related tasks, or to topic notes to show all source materials that mention that topic. This technique is the key to building a truly interconnected and context-aware vault.

Section 4.2: The Interconnected Vault: Bases as Dynamic MOCs

A common practice in Obsidian is the creation of "Maps of Content" (MOCs)—manually curated notes that serve as indexes or tables of contents for a specific topic by listing relevant wikilinks. While effective, MOCs require constant manual upkeep. As new notes are created, they must be manually added to the relevant MOCs.
Obsidian Bases can entirely automate this process, creating "Dynamic MOCs" that are always up-to-date.4 Instead of a manual list of links, a MOC note can embed a Base configured to query the vault for all notes related to that topic.
For example, a note named Project Management MOC.md could contain an embedded Base with a simple filter:
`base
views:

This Base will automatically generate a table of every single note in the vault—whether it's a book summary, a project debrief, a research query, or a fleeting thought—that has been tagged with #project-management. The MOC becomes a living, self-updating index. This not only saves significant time but also surfaces connections that might have been missed during manual curation. The MOC evolves from a static list into a dynamic discovery engine.

Section 4.3: Future-proofing Your System

A well-designed system must also be maintainable. The longevity of this architecture depends on three key practices: schema evolution, data integrity, and leveraging Obsidian's core principles.

Schema Evolution

As workflows change, the need to add, remove, or modify properties is inevitable. When a change is required, the first step is to update the central "Master Property Schema" document. This ensures the official definition of the vault's data language remains current. For implementation, changing properties across a large number of existing files can be tedious. Community plugins like "Linter" or scripts using "Templater" can be configured to perform bulk operations, such as adding a new default property to all files in a specific folder or renaming an existing property across the vault.

Data Integrity

The system's reliability hinges on the consistency of the data within the properties. The primary defense against inconsistency is the rigorous use of templates, as outlined in Section 2.3. However, errors can still occur, and periodic audits are recommended. A powerful data integrity tool can be built using a "Utility" Base. For instance, a view with the filter "where type is empty" will instantly surface any notes that were created without being assigned a proper type, allowing for quick correction.4 Another view could filter for projects where
due_date is in the past but project_status is not "Completed," flagging items that need attention. These simple audit views are essential for maintaining a clean and reliable dataset.

Backup And Longevity

Finally, the most critical aspect of future-proofing is data ownership. The entire system described here is built on top of local, plain-text Markdown files.20 Unlike cloud-based platforms where data is stored in proprietary formats on company servers, this Obsidian architecture ensures that the user retains complete control and ownership of their knowledge. The
.md files and .base files are human-readable and can be backed up, version-controlled with tools like Git, and migrated to any future system with minimal effort. This adherence to open formats is the ultimate guarantee of the system's longevity, ensuring that the meticulously structured knowledge built today will remain accessible and valuable for decades to come.

Conclusion

The architecture detailed in this report provides a comprehensive framework for transforming an Obsidian vault from a simple collection of notes into a sophisticated and unified personal knowledge management system. By embracing a new mental model—viewing Bases not as isolated databases but as powerful, vault-wide query engines—one unlocks the ability to create dynamic, interconnected, and deeply personalized dashboards.
The success of this system rests on three foundational pillars:

  1. A Paradigm Shift to "Vault View Containers": Understanding that Bases are flexible windows into the entire vault, rather than rigid data silos, is paramount. This enables the synthesis of information across diverse categories, fostering a more holistic understanding of one's knowledge.
  2. The Centrality of a Universal Schema: A disciplined, consistent approach to metadata via YAML Properties is non-negotiable. The establishment of a Master Property Schema, enforced through automated templates, is the critical mechanism that ensures data integrity and the reliable functioning of all views and filters.
  3. A Hybrid "Container" Architecture: Strategically grouping related data types into monolithic .base files (like Media.base) while isolating functionally distinct workflows (like Projects.base) provides the optimal balance of efficiency, clarity, and scalability.

By implementing this structure, users can move beyond simple note-taking to become true architects of their digital environment. The result is a system that is not only powerful and organized—rivaling the capabilities of dedicated database applications like Notion and Airtable—but also fundamentally personal, private, and future-proof, grounded in the enduring principles of local-first data ownership. This is not merely a method for organizing files; it is a strategy for building a resilient and evolving second brain.