# Notes Are Files, Not Database Rows: Durability Beats Features The choice of whether your notes live as plain files on your computer or as rows in an application database is treated by users as a feature-set question — does the app I want sync, do graph view, support tags, do AI search — and almost never as the durability question it actually is. Steph Ango, Obsidian's CEO, names the architectural commitment that underlies Obsidian's design directly: "Your notes in Obsidian are just files on your computer. They belong to you, not to the app" (Source: [[3. Resources/Readwise/Snipd/Data/Cortex/179_ The Philosophy of Obsidian, with CEO Steph Ango]]). The claim isn't that Obsidian's feature set is best; it's that the storage substrate determines what survives the eventual end of any given app. A markdown file in a folder remains readable in the next decade's tooling because plain text and basic filesystem operations are stable across decades. A note inside Evernote, Notion, Roam, or any other database-backed app exists only as long as that app's database does — and as long as the export tooling preserves what mattered, which it generally doesn't. The corollary that follows from this commitment is that the app's job is to be replaceable. Ango describes it as a design principle: "Markdown ensures notes remain usable long after the app exists" (Source: ibid). Obsidian deliberately uses commodity formats — Markdown files, YAML front-matter, plain-text wikilinks — that any other tool can read. The vendor lock-in that database-backed competitors enjoy as a retention mechanism is the exact property Obsidian refuses on principle. This produces a strange-looking business model in which the vendor goes out of its way to make leaving easy, betting that the value of staying comes from the tool's quality rather than the cost of leaving. Ango is explicit that the bet is also financial: "We left probably millions of dollars on the table making that choice" — referring to the decision to make commercial license fees optional rather than mandatory. The "files not rows" architecture has second-order effects beyond data durability. Files compose with the rest of the user's computing environment in ways database rows can't. They sync via existing file-sync services (iCloud, Dropbox, Syncthing, git); they edit in other editors (vim, VS Code, mobile markdown apps); they participate in standard backup workflows; they integrate with scripts and CLI tools that operate on filesystems; they can be diffed, version-controlled, grep-searched, and concatenated with the same tools every other file gets. Each of these is a marginal capability the user can defer to existing infrastructure rather than waiting for the vendor to ship. Database-backed apps must reimplement each capability inside their own app, and the user gets only the ones the vendor decides to prioritize. <!-- atomicity: 1 idea ✓ --> ## Why This Matters The implication for **tool selection** is that the "files vs database" question should be a first-class filter when evaluating any tool intended to hold work the user wants to keep for decades. Documentation systems, note-taking tools, journal apps, research databases, recipe collections, photo libraries: each of these has a "files" version and a "rows" version, and the trade-off is consistent. Database-backed versions ship faster, scale better in the short term, and produce nicer demo videos. File-backed versions are slower to delight and harder to scale, but they survive vendor churn. For artifacts the user expects to outlive multiple software cycles, the durability question dominates the feature question. The right default for long-horizon work is file-first. The implication for **AI-era PKM** is sharper than it looks. Ango makes the observation that "people are switching to Obsidian both because they want to use AI and because they don't want AI which is kind of confusing" (Source: ibid). The reconciling insight: both camps want their notes in a format their AI tools (or their non-AI tools) can read. Plain markdown files are LLM-readable by default — any AI workflow can ingest them, embed them, query them — and they're also human-readable by default in a way that produces no privacy surface. Database-backed notes either need to be exported (lossily, periodically) to be AI-readable, or shipped to the vendor's hosted AI feature (creating the privacy surface). The file-first architecture supports both AI futures simultaneously; the database-first architecture supports neither well. The implication for **vendor strategy** is that the businesses that emerge around durable-format ecosystems look fundamentally different from those that emerge around proprietary databases. Ango describes Obsidian's model: "What is paid are our services. So we have sync service and a publish service. And those are optional." The vendor competes on the optional layers (sync quality, publish workflow, collaboration features) rather than on data captivity. This shifts product strategy toward continuous improvement of services, away from increasing friction-to-leave. It's harder to model financially but more aligned with users' interests on the timescale where data-durability questions actually matter. ## Counterpoints to Hold - Plain-file architecture has real costs the database-first alternative avoids: relationships between notes are weaker (you depend on full-text search and wikilinks rather than first-class joins), real-time collaboration is much harder (no central server arbitrating conflicting edits), and certain operations that databases handle trivially (cross-document aggregations, structured queries, transactional updates) become expensive or impossible. For users whose workflow centrally depends on those capabilities, the trade-off may not favor files. - The "files belong to you" claim assumes the user maintains their own filesystem — backups, sync, hardware refresh, eventual migration. Users who outsource that work to Apple, Google, or Microsoft are actually trusting a different vendor, just one further down the stack. The durability claim is real but the locus of trust shifts rather than disappears. - Markdown specifically is a degraded standard. Obsidian extends it (wikilinks, callouts, query syntax), and those extensions don't render correctly in vanilla markdown viewers. The "any tool can read these files" claim is true for the prose but partial for the structure. Defection cost is lower than from a database-backed competitor but it's not zero. - The architecture rewards users who already think in files. Users coming from cloud-native, app-centric workflows often find the filesystem-as-interface overwhelming and prefer the database app's curation. Obsidian's adoption pattern (heavy among engineers, knowledge workers, academics; thinner outside) reflects this user-segmentation reality. ## Links - [[3. Resources/Permanent Notes/Intent Written on the Outside Compounds While Re-Derived Intent Is Debt]] — evidence-for: file-based durability lets written intent survive tools and sessions instead of being reconstructed each time. - [[3. Resources/Permanent Notes/The Slip-Box Thinks With You Not For You]] — the Zettelkasten companion claim; the slip-box works because the substrate (cards, files) outlives any organizing system layered on it - [[3. Resources/Permanent Notes/Information Capture Is Not Formation]] — the substrate-vs-practice distinction at the cognitive layer - [[3. Resources/Permanent Notes/Friction Is the Feature - PKM Tools That Make Synthesis Easier Make Thinking Easier to Skip]] — friction-as-feature applies to file-based PKM; the inconvenience of files-vs-rows is part of what produces the long-term value - [[3. Resources/Permanent Notes/AI-Assisted PKM Replaces Synthesis Work With the Appearance of Synthesis Work]] — durable formats are what make AI-assisted PKM safe(r); the user keeps the substrate even when the AI layer changes - [[3. Resources/Permanent Notes/Permissive Licenses Define a Floor But Don't Constitute a Community]] — adjacent claim about substrate vs practice in open-source contexts - [[3. Resources/Permanent Notes/Long-Horizon AI Shifts the Bottleneck From Model Capability to Memory and Effort Scaffolding]] — applies-in: durable files give long-running agents a writable memory surface they can inspect across sessions - [[Perm · Decoupling from the web means moving content to closed platforms, not achieving independence]] — evidence-for: portable files survive product boundaries, while closed platforms make continued access depend on the vendor ## Open Questions - What's the right archival format for non-text artifacts in a file-first system? Image annotations, hand-drawn diagrams, audio recordings, video clips: each has its own durability question. Obsidian's answer for images is "binary in folder + wikilink reference," which is workable but doesn't generalize easily. - For Excalidraw files specifically (the JSON-in-markdown hybrid format), how durable is the dependency on the Excalidraw plugin's rendering layer? If the plugin disappears, the underlying JSON is still parseable but no longer usefully viewable. This may be a partial-durability case worth a separate note. - Is there a viable file-first architecture for collaborative editing that doesn't compromise the durability properties? Git-backed approaches (gitea, CodiMD) come close but have their own usability friction. The pattern hasn't converged. - For PKM users running Obsidian on iOS/Android, the filesystem semantics differ from desktop in important ways (sandboxing, no real folders, restricted shell access). Does the "files belong to you" claim hold equivalently on mobile? Worth examining. - How does the file-first commitment interact with mandatory data-residency regulations (GDPR, China's data localization, etc.)? If the data is on the user's device, the regulatory questions devolve to the user. If it syncs through Obsidian's optional services, the regulatory perimeter expands. The interaction may be under-examined. ## Source - [[3. Resources/Readwise/Snipd/Data/Cortex/179_ The Philosophy of Obsidian, with CEO Steph Ango]] — Cortex podcast (Relay FM, May 2026): primary articulation of the file-first principle, the optional-services business model, the AI-driven adoption from both privacy-seekers and LLM-users, and the "millions of dollars on the table" explicit choice - See also: [[Personal Knowledge Management MOC]] for the broader cluster this note participates in - See also: [[Visual Thinking MOC]] for the Excalidraw subset where the file-first claim partially holds - [[3. Resources/Readwise/Articles/The 4 Levels of Thinking on Paper]] — connects durable external artifacts to progressively developed reasoning. - [[3. Resources/Readwise/Articles/Obsidian Excalidraw Update (2.24 & 2.25) Smoother Pen Flow, New Scripts & Embeddable Features!]] — shows the practical value and plugin dependency of file-backed visual notes. - [[3. Resources/Readwise/Articles/My reMarkable Obsidian Workflow With the Obsidian reMarkable Sync Plugin]] — demonstrates a capture pipeline that ends in durable Obsidian files.