Obsidian Bases for people who never used databases

When Obsidian 1.9 shipped with Bases, the rollout copy described it as "a database feature for Obsidian." If you read that and immediately closed the tab, you're not alone. Most note-takers don't want a database. They want notes.

But that framing is wrong, and it's caused a lot of people to skip a feature that probably would help them. Bases is not really a database. It's much closer to a saved view of notes you already have, and the moment you see it that way, it stops feeling intimidating.

This post is the version of the explanation I wish someone had given me before I tried (and bounced off) Bases the first time.

The framing problem

The word "database" makes most people think of one of two things:

• A spreadsheet, where you type rows into cells
• A backend system, with schemas and queries you have to design

Neither is what Bases is. Bases doesn't ask you to type rows into cells, and it doesn't ask you to design schemas.

What Bases actually does is much simpler: it takes notes you already have and shows them back to you as a sortable, filterable table. The "rows" are your notes. The "columns" are properties those notes already have. You don't create the data; you re-display the data.

If you've ever wished Obsidian had a way to say "show me all my book notes, sorted by rating" without scrolling through 200 files — that's what Bases does. It's that small, and it's that useful.

What Bases actually is, in one paragraph

A Base is a saved query over your vault, displayed in one of four view types (Table, Cards, List, Map). The query filters your notes by their frontmatter properties — type: book, status: in-progress, tags: vegetarian. The columns of the resulting view are also drawn from those properties. So if your book notes all have type, title, rating, and status, a Base can show them as a table with those four columns. The Base doesn't store anything. It's a window into notes you already wrote.

That's it. That's the whole feature.

When Bases is genuinely useful

Bases helps any time you have a category of notes with shared structure, and you want to see them all at once. The most common cases I've seen:

Reading lists. Every note with type: book becomes one row. Columns: title, author, rating, status, date-finished. Sort by rating descending and you have a "best books" view that updates itself as you finish more.

Project tracking. Every note with type: project becomes one row. Columns: name, status, owner, due-date. Filter to status: in-progress and you have a live dashboard of what you're working on, with each row linking back to the full project note.

Research catalogs. Every paper note with type: paper becomes one row. Columns: title, authors, year, field, my-notes. Group by field and you see your reading clustered by topic without having to organize it manually.

Recipe books. Every note with type: recipe. Filter by tags: vegetarian or prep-time: <30min. The same notes serve different purposes depending on which Base you open.

Meeting logs. Every meeting note with type: meeting. Columns: date, attendees, decisions, follow-ups. A retrospective view across all meetings in a quarter, generated from the notes you were already taking.

The pattern across all of these: you were already structuring the notes. Bases just makes the structure visible at a glance.

When Bases is the wrong tool

Bases is not always the answer. Three cases where you should not reach for it:

You haven't added properties to your notes yet. Bases reads frontmatter. If your notes don't have any, a Base will show you a long list of titles and nothing else. The order of operations is: add a few properties first, let them settle for a week, then build the Base.

You want to type rows into cells. Bases is not a spreadsheet. You can't click an empty cell and type into it. If your use case is "I want to build a small comparison table from scratch", a Markdown table is faster and friendlier. Bases is for re-displaying notes, not authoring tabular data.

You want a one-off ad-hoc view. Building a Base takes 5–10 minutes the first time. If you only need to see the data once, just scroll your notes. Bases pays off when the view is something you'll open repeatedly.

The mental model shift

The single shift that makes Bases click:

In a spreadsheet, the data lives in the cells. In a Base, the data lives in your notes — and the Base just shows it back to you.

Once you internalize this, several things make sense that didn't before:

• Why "row" feels different. Each row is a whole note, not a data entry. Clicking a row opens the underlying note.
• Why columns auto-populate from properties. You don't define columns; you tell the Base which properties to show.
• Why edits in the Base immediately change the note. They're the same data — you're editing through a view of it.
• Why filters and sorts feel powerful. They're queries over your notes, not over an isolated table.

This is also why Bases feels more "native" than a plugin like Dataview, even though Dataview has been doing similar things for years. Bases is built into Obsidian's core, treats the note as the unit, and integrates with the file system in a way that feels of-a-piece with the rest of the app.

How to start without overthinking it

The most common mistake is trying to design a perfect property schema before you've used Bases at all. Don't. The whole feature is designed to evolve incrementally.

A simple first attempt:

1. Pick one note category you have a lot of. Books, projects, recipes, meeting notes — anything where you have at least 10 existing notes with rough structure.
2. Add 2-3 properties to a few notes. Just three is enough. For books: type: book, status, rating. Don't try to capture every dimension; start narrow.
3. Create a Base. Filter to type = book. Choose Table view. Add your 2-3 properties as columns.
4. Live with it for a week. Notice when you reach for it, when you don't, what's missing.
5. Add one more property if needed. Maybe date-finished because you keep wanting to sort by recency. Add it to a few notes; the Base updates.

After 2-3 weeks of this, you'll have a Base you actually use and a sense of which property schemas feel natural in your vault. That's the goal — not a perfect database, but a view you open more than once.

The honest limits

Bases is a 1.9-era feature, which means there are real rough edges. The ones worth knowing about:

Virtualization. Bases doesn't render the whole result set into the DOM at once. For a Base with 100+ items, only the currently visible window is in the DOM; as you scroll, items recycle. This is fine for browsing but creates real problems for any tool that needs to read the full result (export, programmatic access, screenshot of the full view). If you need to get a Bases Cards view out as a single long image, the rendered DOM only has the visible cards.

Type-aware machinery is uneven. Bases Table view has the strongest type handling — checkboxes are real booleans, dates are date types, numbers are numeric. Cards / List / Map views have less of this; they're more visual and less data-faithful.

No formulas yet. Bases doesn't have a formula language for computing column values across rows. If you want "total pages of all books read this year", you can't do that in Bases directly — you'd need Dataview, or you'd need to compute it elsewhere.

Limited cross-Base composition. A Base can't easily reference results from another Base. Each Base is self-contained.

Export gaps. Bases views are great inside Obsidian, but getting them out — as image, PDF, CSV, Excel — is still surprisingly thin. Native export support is minimal; specialized plugins fill some of the gap, but the ecosystem is young. (Disclosure: I work on Table Exporter, which is one of those plugins; it's worth installing only if you actually run into the export friction.)

These limits will erode over the next year as Bases matures. None of them are blockers for the core "saved view of my notes" use case.

What "good" looks like after 30 days

You don't need to track this formally, but a useful check-in after a month of using Bases:

• You have 2-4 Bases you actually open, not 12 you built once
• The properties feel consistent across the note category — you're not adding new properties every week
• At least one view is genuinely faster than scrolling your notes manually would be
• You're not fighting the tool — Bases feels like it's helping, not adding overhead

If all four are true, Bases is working for you and you can keep extending. If one or more are false, scale back rather than push harder. Bases rewards small, consistent use much more than big, aspirational setups.

Where to go from here

If you've never used Bases at all:

1. Pick one note category
2. Add 2-3 properties to 10 notes
3. Build a single Base view
4. Use it for a week before adding anything

If you've tried Bases and bounced off:

1. Look at what you built — was it a view of notes, or did you try to use Bases as a spreadsheet?
2. If the latter, simplify: pick a note category, re-do the steps above
3. Resist the urge to design "the right schema" before using it

The version of Bases that's worth using is small. The version that's intimidating is the one where you try to make it bigger than it needs to be.

---

If you've built a Bases workflow that surprised you with how useful it ended up being, drop us a note — we read every entry, and concrete workflows are the most useful input we get.