Notion or Obsidian: where the notes actually live

The difference between these two is not the feature list; it is custody. In Obsidian the notes are files on a disk you control, and the app is a reader for them. In Notion the notes are rows in a workspace somebody else runs, and the app is the only way in.

Who holds the file?

Obsidian opens a folder of Markdown files. Each note is a text file, attachments sit beside it, the links between notes are written into the text. If the app disappeared tomorrow the notes would still open in any editor and still commit to a repository. That property is the product.

Notion holds the content in its own store and serves it to you. Export is real, but it is a rendering of the workspace rather than the workspace's own format: what you get is documents shaped by the export, not the structures that produced them.

The W3C's data on the web best practices treat a portable format as a property of the data, not of the app reading it — worth checking before you put years of notes inside one.

What happens on the day you stop paying?

In Obsidian the app is licensed per person and the files keep working. Stop paying for sync or publishing and you lose the convenience, not the notes.

In Notion the workspace is the subscription. When it lapses the content does not vanish at once — usually a read-only window and an export path remain — but the team loses editing, outside links stop working, and the structure becomes a pile of documents. The exit is a project, not a menu item.

What does "database" mean in each?

In Notion a database is a first-class object: rows with typed properties, relations to other databases, rollups across them, several views of the same rows. The table is not a file but a structure the product understands, and the page a row opens into is part of it.

In Obsidian properties live in the file's frontmatter and every table is a view over them — the app's own database view reads those properties, and a community plugin did the same job before it existed. The difference is where the truth sits: here the file is the truth and the table a query; there the database is the truth and the page one of its rows.

Teams pick wrong here more than anywhere else. A supplier list with a status and an owner is an operational record, and Notion's database is its natural shape. A set of decisions and specifications is a body of writing, and a database-first tool tempts the team to turn it into rows — which is how you get a "Projects" table nobody updates.

How does a team of five share notes with no IT?

Notion's answer is in the product: an account, a workspace, pages shared with people or everyone, roles, a guest link. A small team is running in an afternoon, and permissions are decided per page with an inherited default.

Obsidian's answer is a folder plus a way to sync it. The paid sync service is the simple route; a network drive, a Git repository or a third-party sync folder are the cheap ones, and each brings a trap. A shared folder gives everybody every note — there is no per-page permission, so salary notes cannot live beside the handbook. A Git repository gives history and conflict markers, excellent for people who read diffs and hostile to those who do not. Two people editing the same note at once breaks every one of them.

For five people who all read everything, that trade is fine. For five where one must not see the salaries page, it is not a trade: no plugin adds the permission a lawyer would accept.

Which migration is easy, and which is lossy?

Obsidian to Notion is the easy direction. Markdown imports as pages, folders become nested pages, the text survives. The linking does not fully: wiki links may or may not resolve, embeds often become attachments, and anything a plugin computed arrives as plain text. The notes are there; the machine that read them is not.

Notion to Obsidian is the honest lossy one. The export gives Markdown per page and a CSV per database, and the two arrive disconnected: the CSV knows the values but not which page each row was, and the page does not know it belonged to a row. Relations, rollups and saved views have no equivalent, so you get the content and a puzzle.

Choose the direction you can afford to be wrong about: moving into a hosted workspace is reversible in content, moving out is reversible in content and expensive in structure.

The question	Obsidian	Notion
Where the note lives	A Markdown file in a folder you own	A workspace served by the vendor
When the payment stops	The files keep working	Read-only, then an export project
What a database is	A view over properties in the files	The object itself, with typed rows
Sharing with five people	A synced folder; no per-page permissions	Accounts, roles, guest links

How do you decide, in order?

1. Write down what the notes are for: a body of writing that references itself, or a set of records with statuses and owners.
2. Name who must not see what. If one page must be closed to someone, the file-based model is disqualified for that collection.
3. Export a real sample and open it in a plain editor. The mess you see is the cost of leaving, measured in advance.
4. Decide who may break the format: plain files invite everyone to invent a structure, a hosted workspace imposes one.
5. Choose the simplest sync the team can operate without help, and re-check the decision when the team doubles — that is when the sharing model stops fitting.

Where this goes wrong

• The vault with no convention. Plain files let each person invent a folder scheme, and a year later nobody finds anything. The freedom is real; it costs a convention someone enforces.
• Sync treated as backup. A synced folder propagates a deletion everywhere in seconds; the difference is discovered on the worst day.
• Migration planned as a copy. The files arrive, the structure does not, and the team keeps the old tool for the tables for another year.

What this leaves out

It gives no prices: both are sold on plans whose contents change, and a figure here would be stale before the page was read. Check the vendor's page for what each tier includes today.

It also does not cover self-hosted alternatives, regulated record-keeping, or search across a large corpus. We build and integrate systems around tools like these; we resell neither product and take no commission, so the comparison carries no commercial interest.

We build the layer that finds things in a company's own notes and documents — and we would start from who may read a note and what happens when the subscription lapses, because those two questions pick the tool long before the editor does.