Obsidian Canvas vs. Heptabase: How File-Centric and Card-Centric Architectures Shape Spatial Thinking

At first glance, the Obsidian Canvas vs. Heptabase debate looks like a choice between two similar spatial note-taking tools. Both give you an infinite 2D canvas, both let you arrange notes side by side, and both let you draw arrows between ideas. Under the hood, however, their data architectures are fundamentally opposite. The short answer: Obsidian Canvas stores visual arrangements inside individual .canvas files using the open JSON Canvas format. In Heptabase, whiteboards are non-owning visual views over a central card library. In practice, this means a line drawn on an Obsidian Canvas creates no link between notes in your vault, while a line drawn on a Heptabase whiteboard creates a connection both cards remember. In short: Obsidian’s connections are portable across external tools but unindexed in your vault’s graph; Heptabase’s connections are indexed across your cards but locked into its proprietary ecosystem. If you are trying to decide whether to build your long-term knowledge workflow in Obsidian Canvas or invest in a dedicated spatial tool like Heptabase, looking at UI features won’t give you the answer. You have to look at how each tool models files, cards, and context. Architectural Breakdown: Obsidian Canvas vs. Heptabase Architectural DimensionObsidian CanvasHeptabaseFirst-Class CitizenFiles (.md notes and .canvas files)Atomic Cards (Global entities across the workspace)Spatial OrganizationEmbeds Markdown files or local text cards inside an open JSON Canvas fileMaps global cards as live views across multiple whiteboards simultaneouslyWhat Connection Lines MeanVisual coordinates stored in the board file; portable across tools, but unindexed in the vault graphRelational connections surfaced in the Card Info panel; indexed in the workspace, but locked into the appContext AwarenessCanvas-bound: Context lives in the canvas file, not in the note itselfContext-aware: Every card tracks all whiteboards it belongs to and all connected cardsPortability vs. IndexingPortable, but unindexed: The .canvas file uses open JSON Canvas, but notes remain unaware of connectionsIndexed, but proprietary: Connections compound across boards, but cannot be exported as an open interactive graphBest FitProject roadmaps, system architecture diagrams, and visual brainstorming sketchesCumulative research and long-term thinking bridging spatial exploration and linear writing Obsidian Canvas: A Visual Layer Stored Inside a Single File Obsidian is built on a local-first philosophy: your knowledge base is a folder of plain-text Markdown files. Obsidian chose the file as its atomic unit. That choice is what makes a vault portable and durable—and it is also why a canvas can only be another file, with nowhere to store a connection except inside itself.

1.

Spatial Organization: Embedding Files into a Single Canvas When you create an Obsidian Canvas, you create a standalone .canvas file (stored on disk as JSON). This creates an immediate architectural split: Cards created inside the canvas stay inside that file. If you type out ten quick thought cards directly on a canvas, those cards exist only inside that .canvas file. They do not appear as independent notes in your vault unless you manually convert them into separate Markdown files one by one. External notes are embedded views. When you drag an existing .md file onto a canvas, Obsidian renders an editable viewport into that file. However, the canvas is simply referencing the file’s path from the outside.

2.

Connecting Ideas: Visual Lines vs. Real Graph Links In a spatial workspace, the lines connecting notes often carry as much meaning as the notes themselves. In Obsidian Canvas, the arrows you draw on a board are stored as visual coordinate data inside that specific .canvas file. They do not register as Markdown links or [[wikilinks]], and they do not appear in Obsidian’s global Graph View. If you draw an arrow from Note A to Note B on a canvas, the core link engine records no link between the two notes. This architectural limitation is a frequent discussion point among users. In an Obsidian community forum thread introducing the Canvas Links plugin, one user noted: “visual connections in the canvas are not actual links and so don’t show up in graph view.” While community plugins can bridge embeds and show which canvas references a file, the core canvas lines remain localized visual data rather than relational graph links.

3.

Context Awareness: Context Lives in the Canvas, Not in the Note Because Obsidian’s architecture is strictly file-centric, Markdown files and .canvas files are structurally separated. If a Markdown file is embedded across multiple canvases, it is simply being viewed from the outside. The file itself stores no metadata about its visual placement: When you open the note in your regular editor, it does not display which canvases currently contain it. It does not know what neighboring cards sit next to it on any canvas. It cannot see what arrow labels or connections point to it. The moment you leave the .canvas file, that spatial context stays behind in the canvas file, leaving the note as an isolated piece of linear text. The Verdict on Obsidian Canvas Obsidian Canvas is best suited for visual brainstorming, process flowcharts, and system mapping. Because connections remain within the canvas file, it is less suited for atomic notes that need to accumulate links across many boards over time. Heptabase: A Context-Aware Thinking Workbench Heptabase approaches spatial note-taking from the opposite architectural perspective. Instead of treating the whiteboard as a container file that embeds independent documents, Heptabase separates what a note is from where a note is viewed.

1.

Spatial Organization: Whiteboards as Non-Owning Views In Heptabase, the atomic unit of the system is the card rather than the file. As defined in Heptabase’s official documentation on Fundamental Elements: “Whiteboards do not own cards.

All cards belong to the Card Library.

The same card can be placed on multiple whiteboards at the same time.” Because whiteboards are non-owning visual views over a central library, placing a card on a whiteboard does not isolate or nest it. You can place the exact same card across multiple whiteboards simultaneously without duplicating content or breaking sync. An update made to a card on one board immediately reflects everywhere else that card appears.

2.

Connecting Ideas: Whiteboard Connections in the Card Info Panel When you draw a connection line between two cards on a Heptabase whiteboard, the relationship is reflected directly in the workspace outside the board itself: Open Card A’s Card Info panel, and it lists Card B under its connected cards, noting the whiteboard where the arrow was drawn. Open Card B’s Card Info panel, and it displays the incoming connection from Card A. Clicking a connection entry in either card jumps you directly to that exact spatial coordinate on the whiteboard. While inline @mentions in card text handle linear cross-references, whiteboard lines provide a dedicated spatial linking layer that cards track wherever they are opened.

3.