Capacities vs Obsidian

Capacities is built around a real bet: that objects, not files, are the right unit for a knowledge base, with an AI assistant that already reads what's inside it. Obsidian is built around the opposite bet. Both are defensible. They are not solving the same problem.

Open Capacities and the first thing the product tells you is that you're not creating files, you're creating objects: people, books, projects, ideas, each with its own structure and properties. A meeting becomes an object with attendees and a date. A book becomes an object with an author and a rating. That's a genuinely different mental model from Obsidian's flat folder of markdown notes, and it's the whole reason people who like structured databases gravitate here instead.

Beyond notes: calendar and tasks baked in

Capacities doesn't stop at notes. Its Pro tier folds in calendar integration and task management as first-class parts of the same object model: a meeting on your calendar becomes an object you can link attendees, agendas and follow-ups to, and tasks live wherever they're relevant, on a project, a person, or your daily note, rather than in a separate app. That's a genuinely different pitch from Obsidian, where the same outcome exists but only after installing and configuring several separate community plugins for calendar sync and task tracking, each maintained by a different volunteer and each with its own quirks. Capacities is betting that most people would rather have one product handle notes, tasks and calendar with a single mental model, even at the cost of it being a hosted product; Obsidian is betting you'd rather assemble exactly the stack you want, file format included, even if that means more setup.

What the AI actually does

Capacities Pro adds an AI layer that's more capable, out of the box, than anything Obsidian ships natively. You can chat with any note and get answers grounded in what's actually written there. Create a book object and the AI will fill in the author, genre, and summary on its own. Smart commands can summarize, translate, or critique a note in place. There's also a contextual suggestion feature that proposes tags and properties based on what you've written, though the product is explicit that you approve or ignore each suggestion rather than it filing anything unattended. Dynamic queries let you build views like "tasks due this week" that stay current automatically, but you still have to build the query.

The cost of the object model

The trade for all that structure is the same one every hosted, object-based tool makes: your notes live inside Capacities' own format, synced through its own backend, not as files you can open elsewhere. That's not a criticism unique to Capacities, it's the same architecture question worked through across every method covered in PKM methods compared, and it's worth being deliberate about before your whole knowledge base is built on a proprietary object model rather than plain text.

The migration question people actually ask

The practical worry with any object-based tool is what happens if you leave. Capacities does offer export in standard formats, so you're not fully stranded, but an "object" doesn't map cleanly onto a markdown file the way a Notion page roughly does. A book object with a dozen typed properties becomes, at best, a page with those properties listed as text once exported, and the typed structure itself, the thing you were paying for, doesn't survive the move. Obsidian has no equivalent problem because there was never a proprietary structure to lose in the first place. That asymmetry is worth weighing before your whole knowledge base leans on typed objects you can't fully take with you.

Which one to pick

Pick Capacities if structured, typed data (books, people, projects with real properties) is how you actually think, and you're comfortable with a hosted backend in exchange for a genuinely capable AI layer. Pick Obsidian, and look at what actually fills the filing gap Obsidian leaves open, if the plain-text promise matters more to you than the convenience of typed objects. Neither is wrong. They're answering different questions.