# Obsidian Bases: a technical deep-dive into Obsidian’s “database-like” notes ![[base1.png]] Obsidian has always been “notes first.” **Bases** flips that around (a bit): it lets you treat a _set of notes_ as rows in a database-like view, where each note’s **Properties** become columns you can **view, edit, sort, filter**, and even compute with **formulas**. It’s a core plugin (not a third-party add-on), and it’s aimed at the sweet spot between “plain-text vault” and “Notion-style database.”  This post goes deep on what Bases is, how it works under the hood, where it shines, where it breaks down, and why it’s an unusually relevant tool in a world full of cloud databases. --- ## **What are Obsidian Bases?** At the simplest level: - A **Base** is a **database-like view** over a collection of files in your vault.  - Each **row** is a file (typically a note). - Each **column** is a **Property** (YAML frontmatter / Properties UI), plus a set of built-in “file properties.” - Each Base can contain multiple **views** (table/cards/list/etc.), with their own layout, filters, and sorting.  When you create a Base in Obsidian, it’s saved as a **.base file** (YAML) that defines: - what files are included (via filters), - what columns to show, - how views are laid out, - and any formula-driven fields.  This matters because it means Bases isn’t “a separate database system.” It’s a _lens_ over files you already own. --- ## **How Bases works (and why it’s different from Dataview)** ### **The data model: “notes as records”** Bases assumes the vault already contains: 1. **Files** (notes), and 2. **Structured metadata** in **Properties** (frontmatter). That’s why many people migrating from Dataview have to move metadata _into frontmatter/properties_ to get the most out of Bases.  ### **Storage:**  ### **.base** ###  **files are YAML** Bases definitions live in .base files and must be valid YAML matching Obsidian’s Bases schema.  You’ll typically edit Bases through the UI, but you _can_ edit the YAML directly (and even embed a base definition in a code block).  ### **Querying: filters + formulas** Bases provides: - **filters** (to choose which files belong), - **sorting/grouping** (depending on view), - and **formulas** (computed values).  It’s “database-like,” but it’s not SQL, and it’s not trying to be a full relational engine. --- ## **A concrete example: a Projects Base** Imagine you keep one note per project in Projects/ and each note has properties like: ``` --- status: active area: Consulting due: 2026-01-15 priority: 2 client: "Acme Dental" --- ``` A Base can then show: - columns: file.name, status, client, due, priority - filter: only status = active - sort: due date ascending, priority descending Conceptually you end up with a Notion-like database table — but each row is still _a note you can open, link, and edit like any other note._ --- ## **Case studies: how Bases can be used in the real world** Below are practical patterns that show where Bases is genuinely useful (and where it’s only “okay”). ### **Case study 1: Task-light project tracking (without a full PM app)** **Problem:** You don’t need Jira/Trello. You need a lightweight list of active projects, their due dates, and current status. **Vault structure** - Projects/Project A.md - Projects/Project B.md **Properties** - status (idea | active | waiting | done) - due (date) - next_action (text) - area (Work | Volunteer | Home) **What Bases gives you** - A single “Active Projects” table view filtered to status = active - A “Waiting” view filtered to status = waiting - Quick inline edits (change status, due dates, etc.) right in the table  **Why this is better than a tag search** - You get **sortable columns** and **editable fields**, not just a list of links.  --- ### **Case study 2: Reading list with computed fields (“time-to-read”, “next up”)** **Problem:** You want a personal library tracker that doesn’t live in a cloud service. **Properties** - author - type (book | article | paper) - status (to-read | reading | finished) - pages or words - rating - started / finished **Formula ideas** - compute estimated reading time from words / reading_speed - compute “days reading” from today - started **Reality check** Community feedback shows that some “dynamic file properties” and formula-like features may be most visible/usable _within Bases itself_ (not everywhere in-note), which is a current pain point for people who want computed values to appear in frontmatter universally.  --- ### **Case study 3: Academic notes & literature triage** **Problem:** You’re collecting sources and notes and need a “papers dashboard” to filter by topic, method, or relevance. A recent academic-focused writeup describes using Bases as a filterable, editable table of notes (papers) driven by tags/folders/properties.  **Pattern** - One note per paper - Properties: year, topic, methods, claims, relevance, status, bibkey - Base views: - “To Read” (status filter) - “High Relevance” (relevance filter) - “By Topic” (group/sort) **Why Bases is a fit** - The “one note per source” model maps cleanly to rows. - Academic triage benefits from fast sorting/filtering and consistent properties. --- ### **Case study 4: A volunteer roster / training tracker (Coast Guard Auxiliary / church teams)** **Problem:** You need a roster of people, certifications, expiration dates, and assignments — but you want it local and linkable to notes about each person. **Structure** - People/Jane Doe.md - People/John Smith.md **Properties** - role (FSO-IS, team lead, etc.) - certs (list) - cert_expires (date) - availability (text or select) - phone, email **Base views** - “Cert Expiring Soon” sorted by cert_expires - “By Role” grouped/sorted by role - “Contact List” cards view **Why this works** - It’s a database, but it’s also a knowledge base: each row is a real note with context, history, links, and attachments. --- ### **Case study 5: “Home inventory” that isn’t a spreadsheet** **Problem:** You want to track equipment (drives, routers, laptops, etc.) with serial numbers, warranties, and location. **Properties** - category - model - serial - purchase_date - warranty_ends - location - status (in use | spare | retired) **Value** - A Base becomes your inventory table, but each item note can include photos, receipts, troubleshooting logs, and linked projects. --- ## **Strengths of Obsidian Bases** ### **1) Local-first database views on top of plain text** Bases inherits Obsidian’s core premise: you own the data, and it lives as files. The .base file is just configuration.  ### **2) Tight integration with Properties** Bases is built around viewing/editing a note’s Properties directly in a database-style interface.  ### **3) Multiple views per dataset** One dataset; many lenses: tables for analysis, cards for browsing, filtered views for workflows.  ### **4) Extensible for developers** Obsidian’s developer docs explicitly describe building custom Bases views via the API, meaning plugins can extend how Bases data is rendered/used.  ### **5) UI-driven, but still editable as text** The YAML-backed .base format means your “database setup” can be version controlled, shared, and reviewed like code.  --- ## **Weaknesses and sharp edges** ### **1) It’s (mostly) frontmatter/properties-centric** A common complaint: Bases “wants frontmatter in every file,” and can be blind to metadata patterns that live outside the YAML/Properties model.  If your vault uses: - inline key:: value fields, - metadata embedded in the body, - or heavily unstructured notes… …you’ll feel friction. ### **2) Filtering by note**  ### **content** ###  **is limited** A feature request highlights that Bases filters are currently property-based, and people want to filter based on the actual body text (e.g., ingredients in a recipe note).  So if your “data” is truly in prose, Bases won’t magically turn it into queryable fields. ### **3) Schema discovery and full syntax can be opaque** Even in 2025, users were asking for “full Bases documentation” because some options weren’t obvious from the official syntax examples, and people resorted to inspecting .base files created via the GUI.  ### **4) Not a relational database** Bases is excellent for “one note = one record.” It’s less satisfying when you want: - joins, - many-to-many relations with constraints, - transactional behavior, - strict typing and validation beyond what Properties provides. You can approximate some relationships with links and multi-value properties, but it’s not the same as relational modeling. ### **5) Computed fields may live “inside the base”** There are requests to expose formula/file properties more broadly across Obsidian, suggesting that some computed goodness is currently most at home inside Bases views.  --- ## **Bases as a “useful database” in today’s world** We live in an era where “database” usually implies: - cloud-first, - collaborative, - subscription, - and often opaque export paths. Bases lands in a different philosophy: ### **It’s a database without giving up note-ness**  Unlike a traditional database table where a row is “just a row,” an Obsidian Base row opens into a full document: - narrative context, - backlinks, - attachments, - links to other entities, - and a long-form history. That hybrid is powerful: it supports both **structured retrieval** (filter/sort) and **unstructured understanding** (the note itself). ### **It’s resilient and portable** Because the underlying records are files: - your “database” can be backed up with your vault, - synced however you like, - and not trapped behind a vendor’s schema or export limitations.  ### **It encourages “good metadata hygiene”** Modern knowledge work often fails because information is either: - too rigid (forms-only), or - too loose (everything is prose). Bases nudges you toward the middle: enough structure to compute and filter, but still human-friendly because the record is a note. ### **The trade-off is discipline** Bases rewards consistent properties. If you won’t (or can’t) normalize metadata across notes, Bases becomes less “database” and more “pretty list.” --- ## **Practical guidance: when to use Bases (and when not to)** **Use Bases when:** - you can model something as “one note per entity” (project, person, book, asset, client) - you’re willing to maintain a small set of consistent properties - you want local-first tracking with fast filtering and editing **Avoid (or limit) Bases when:** - your “data” lives mainly in the body text and you can’t extract it into properties  - you rely heavily on non-frontmatter metadata patterns  - you truly need relational constraints and joins (use a real database or a dedicated tool) --- [[Obsidian as a PKM]] [[Obsidian Quick Add]] [[Dataview for Obsidian]] [[PKM]] [[Note Taking in the Digital Age]] [[Advice for someone stuck with Obsidian and Omnifocus]] [[Building Your Personal Knowledge Management (PKM) and Second Brain with Obsidian- A Comprehensive Guide]] [[Best Practices for Task Management and GTD with Apple Reminders]] [[TimeGarden-Obsidian]] [[The Three Biscuit Method of Management]] [[The Importance of Privacy--Why Average People Should Care]] [[Understanding Data Privacy]] [[Understanding Network Encryption and Security]] [[The Daily Note]] [[The Tech Pastor|home]] ◦ [[Contact]]