Obsidian Bases vs Notion Databases: Features, Workflows, and Trade-Offs

2025 has been huge for the landscape of personal and collaborative knowledge management tools. Notion and Obsidian have been some of the most popular tools in this space for a while, but for fundamentally different reasons. A comparison of all the differences is a whole other post, which will come soon, but to oversimplify: Notion is cloud-based, online, with powerful database structures and geared towards collaboration. Obsidian is local-first, offline; any database functionality required custom plugins, and it's geared primarily towards individual users. Until now. Notion has begun rolling out its offline mode feature to some users, in an early stage of development. Obsidian has released its beta of Obsidian Bases, bringing database functionality to Obsidian users. To note, this is just available through Obsidian Catalyst while in beta.

Keep in mind that, at present, comparing database functionality probably isn't a fair fight. Notion has been in this space for years and Obsidian Bases are still in beta with more functionality; additional views, etc. coming down the line.

In 2025, the landscape of personal and collaborative knowledge management is rapidly evolving, with Notion and Obsidian emerging as two of the most influential platforms. Notion’s database functionality is mature, feature-rich, and optimised for collaboration, while Obsidiannew Bases feature introduces local-first, markdown-powered structured data handling for users who demand full data sovereignty and customisability. This report provides a comprehensive, expert-level comparison, including a side-by-side feature table, workflow examples, performance benchmarks, and a critical analysis of the trade-offs. My findings indicate that Notion remains the superior choice for collaborative, relational, and highly visual database use cases, whereas Obsidian Bases excels for solo users, privacy advocates, and those who require offline, extensible, and scriptable workflows. Hybrid strategies and workflow-specific tool selection are recommended for advanced PKM practitioners.

Disclaimer

I'm a long-term Notion user and love the tool. I've spent some time working in Obsidian but am by no means an expert. I've primarily looked at Obsidian Bases through the lens of creating my Notion structure within Obsidian. This approach probably does Obsidian a disservice because I'm not optimising my setup based on Obsidian’s own feature set.

Why am I trying Obsidian?

I value the database structure in my Notion workspace but have always loved the knowledge graph views in Obsidian. The availability of highly custom/niche plugins is also a big appeal of Obsidian. I use Notion for worldbuilding projects for TTRPGs and there are some capabilities I just can't create in Notion; interactive maps, fantasy calendars, dice rollers etc. that are just an install (and probably some configuration) away in Obsidian.

The introduction of Bases sounded like a good opportunity to get the best of both; database structure and high customization. I'll follow up with another post on how I found using both tools for worldbuilding specifically, but for now let's focus on databases.

For those interested in worldbuilding within Notion, I've put together the Worldbuilding Kit 1.0.0, which leverages Notion's database structure for managing campaign settings, lore, and more. For running encounters at the table, the D&D Encounter Manager handles combat tracking and encounter planning.

Comparison of Data Structures

Notion’s databases are containers of pages (each record is a full Notion page)notion.com. Users define properties (columns) such as Title (text), Select/Multi-select, Date, Number, Checkbox, Formula, Relation, etc. Every record can hold rich content (text, images) inside its page.

Obsidian Bases, by contrast, assemble data from Markdown notes in your vault. Each row in a Base corresponds to one Markdown file; columns come from fields declared in that note’s frontmatter YAML. For example, one might tag notes or add properties (date:, status:, etc.) in YAML.

Each note acts as a "row," and YAML properties serve as "fields." The new .base file format allows users to define table views over sets of notes.

All data in an Obsidian Base are stored in plain-text files locally first. Notion's proprietary, cloud-based database system stores each entry as a "block" in a sharded PostgreSQL backend. This means a couple of things:

• For Obsidian users, this ensures maximum portability and privacy: if Obsidian were ever discontinued, the notes (and their properties) remain fully accessible. Notion’s data, by contrast, live in Notion’s proprietary cloud database, though Notion does offer export options. I haven’t availed of the export functionality really but from what I’ve read up on it, exporting to a new tool wouldn’t be a seamless process.
• Notion’s approach easily enables robust multi-user access, real-time updates, and seamless cross-device sync, but ultimately, places all data under Notion’s control.

Visually, I’ve found that each tool’s data model leads to different workflows. In Notion, you often start by creating a new database (a page with an underlying table or board view). In Obsidian, you create notes (often via templates) first, then create a Base to query/filter those notes into a table. Notion therefore emphasizes designing the database schema upfront, while Obsidian emphasizes annotating each note and then querying across them. This difference reflects each tool’s philosophy: Notion is database-first, whereas Obsidian is note-first.

Views, Layouts, and Visualization

Notion natively offers a wide range of database views. By default, a new database opens in Table view, but users can easily add Board (Kanban), List, Calendar, Timeline, Gallery, or Chart views. Each view can have its own filters, sorts, and displayed properties. For example, one might group tasks by status in a Board view, or view project deadlines in a Calendar. Advanced grouping (e.g. nested group-by) is built in.

Obsidian Bases currently have only a single Table layout. The Obsidian “Bases” core plugin (as of mid-2025) allows users to create multiple Views of the same base, but all are table-structured for now. A view is defined by its filters and visible columns; users can duplicate views, export to CSV, or embed a view in a note. The official roadmap indicates that other layouts (list, card, gallery) are planned but as of now one cannot create a Kanban or calendar view without third-party plugins. Dataview looks to be the most popular plugin for this, but requires a lot more configuration to set up.

Aesthetically, in my opinion, Notion views are highly visual, they often appear more “polished.” For example, Notion’s Gallery view shows records as cards with images, and Board view shows draggable columns. Obsidian’s Table view looks and feels like a spreadsheet of Markdown files. Notion even allows custom styling (colors, icons) per entry in some views. Obsidian’s table is basic by comparison but is way more customisable overall if you go down the road of custom themes and plugins. In summary, Notion excels at offering out-of-the-box rich visuals and multiple angles on the data, whereas Obsidian currently provides a single, uniform table interface with more view types slated.

Filters, Sorting, and Grouping

Both tools support filtering and sorting, but the UX differs. In Notion, filters and sorts are configured via dialog menus for each view. Notion users can add simple or advanced filters (combining AND/OR logic) through a point-and-click interface. In Obsidian Bases, filters are defined using a query builder or YAML-like syntax: users specify conditions on properties (e.g. status = "Done", date > 2023-01-01, or use functions like contains()). Complex filter groups can be built with AND/OR as well, but this requires writing conditions rather than clicking checkboxes.

Notion’s grouping feature lets you roll up rows into buckets by a property value (e.g. grouping tasks by project or status). Obsidian Bases do not yet support view-level grouping; rows are always in a single flat list. (However, one could mimic grouping by filtering for one category at a time or by sorting). Sorting by one or more properties is available in both: Notion provides dropdown menus to set sort order, and Obsidian allows specifying sort keys in the view definition.

Relational Data and Rollups

This is the most interesting space for me. Notion's relation functionality is, for me, its most powerful feature, but it has one flaw that Obsidian Bases almost solves.

In Notion you can add a “Relation” property in one database linking to records in another. This automatically creates a two-way link: related pages can be opened and edited in place. Once related, you can add a Rollup property to aggregate data from the linked records (e.g. count related tasks, sum hours, concatenate tags). This makes it easy to build connected systems (e.g. Projects ↔ Tasks databases, or Customers ↔ Orders). I find it very easy to use and it is an intuitive way to link data across tables.

Obsidian inherently has wiki-style links and backlink lists, but Obsidian Bases currently have no native relational property. A Base cannot natively reference entries in another Base or table exactly. In practice, you can reference other notes via YAML properties or Obsidian’s native backlinks and see those backlinks at the ‘database level.’ However, it lacks the ability to create explicit, enforceable relationships between tables (e.g., foreign keys, multi-table rollups). This limits its suitability for complex, multi-table workflows (e.g., advanced CRM or inventory management).

In essence, Notion creates and visualises relationships between notes/pages really well at the database level. Obsidian backlinks do this really well at the page/note level.

What I would like to see most in Notion is a feature to bridge the disconnect between the page content and the database properties. I can fill my page with rich content and mention pages (mentions are comparable to obsidian backlinks) across my workspace but I can’t see that data information at the database level.

Obsidian allows me to view that data at the database level by referencing backlinks in a property but I then can’t interact with it at the database level. i.e. I can’t add an additional backlink to that property at the database level if that makes sense. (At least, I couldn’t figure out a good way to do it.)

I've actually explored a workaround for this exact limitation, which you can read about in Building a Notion Mentions > Relation Automation.

If you're looking for a practical example of how Notion's relational database capabilities come together in a fully connected system, the System Blueprint is a template I've built that demonstrates exactly this kind of interconnected database architecture.

Data Manipulation and Formulas

Notion allows rich data manipulation via Formula properties. Users can create formula columns that perform math, string operations, date arithmetic, or conditional logic. Notion provides many built-in functions (e.g. dateAdd(), now(), length(), if() and logical operators) that can use any property’s value. For example, one can compute “Days Overdue”, “Priority Score”, or count related items entirely within the database. The formula editor is embedded in the UI: users click “Add a formula property” and then enter an expression.

Obsidian Bases similarly support functions in Filters and Formulas, but with a more code-like syntax. The help docs list functions for dates, strings, lists, files, etc. (e.g. date(), format(), contains(), now(), if(). For example, one could filter on status="Done" or compute a value like toString(file.day). However, there is no dedicated “formula column” in the Base view – formulas appear only in filter or sort expressions. In practice, this means advanced calculations often require writing the expression manually. The advantage is flexibility: the Obsidian function set is extensive and can even include plugin-provided functions. The downside is usability: Notion’s formula helper guides or examples make it a little easier for beginners, whereas Obsidian users may need to learn the query syntax or refer to docs. There is a learning curve to both but I believe Obsidian’s is a little steeper in this regard.

In summary, both tools offer strong formula support, but Notion’s is more user-friendly and visual, while Obsidian’s is more developer-oriented and requires text input. Both can handle dates, math, and text, but only Notion ties formulas into the database UI as properties.

Strictly in terms of database functionality, Notion is in the lead, though I can see Obsidian closing this gap relatively quickly. But will you choose either tool based on database functionality alone? Likely not. Ultimately, Notion offers a more mature, user-friendly database environment with advanced relational capabilities, but what it really offers is built-in collaboration – making it the better choice for team projects and complex interlinked data models. Obsidian's Bases provide a fresh, local-first approach to structured data: all notes are yours, offline, and editable in plaintext, with the trade-off of a steeper setup and fewer out-of-the-box features.

If open-source flexibility and data sovereignty are paramount, or if one already lives in the Obsidian ecosystem, then Bases could replace many Notion database use cases. If ease of sharing/collaboration and rich formula/relational tools are required, Notion still leads.

For a deeper look at how I put these ideas into practice for my own PKM workflow, check out Building a Personal Knowledge Management System.

If you're exploring how to structure your own knowledge management setup in Notion, check out the Knowledge Management Kit 2.2.4. It brings together the database architecture, relations, and views discussed throughout this post into a ready-to-use system for managing your personal knowledge base.

More from the Blog