If you are picking a note system, the folders-versus-tags debate is a distraction. The decision that shapes everything after it is where your notes physically live: as plain text files on disk that you own, or as records inside an app's database that you reach only through that app. Each side has a real cost. This article lays them out so you can pick the cost you can live with.
The verdict
If you expect to keep these notes for more than five years, or you want to script over them, choose plain files. If you value linking, collaboration, and mobile capture more than portability, choose a database, and read up on how its export works before you commit anything important to it.
The two sides, defined
Plain files. Each note is a text file on your disk, usually written in Markdown, a lightweight formatting syntax where headings, bold text, and links are typed as literal characters (# Heading, **bold**). A text editor from any vendor can open the file, because there is nothing in it but text.
App database. The app stores your notes in its own structure, either in a local database file or on the vendor's servers. You read and write notes through the app's interface. If there is a file on disk, it is not designed for anything else to open.
Side by side
| Plain files | App database | |
|---|---|---|
| Who holds the bytes | You | The vendor, on your behalf |
| Opens in | Any text editor | That app |
| Rich features | Bounded by plain text | Built in |
| Cross-device sync | You set it up | Usually included |
| Scripting | Direct | Through export or API, if offered |
| Outlives the app | Yes | Only as well as its export |
What plain files cost you
Rich features stop at the edge of the text
Backlinks (a list of which other notes point at the one you are reading), embedded views, per-paragraph comments, and shared editing depend on an index that some program maintains. With files, your editor builds that index from the text. Switch editors and the index is rebuilt from scratch, using only what was written into the files as literal characters. Anything the old editor kept outside the text does not travel.
That is the boundary: a feature is portable only if it can be expressed as text. Plenty can. A link written as [[note title]] is text, and a different editor can be taught to read it. A block-level comment thread stored in the app's own index is not.
Sync is your problem
An app with a database ships sync as part of the product. With files, you assemble it: a cloud-drive folder, a file-sync service, or a version control system such as git, which tracks changes to text files and can merge edits from different machines. Each works. Each also puts you on the hook when two devices edit the same file while offline and you get a conflict copy to reconcile by hand.
Mobile capture is where this bites. You need an editor on the phone that can reach the same folder, and getting a quick thought from your lock screen into the right file takes more steps than it does in an app built around capture.
Collaboration is one-at-a-time
Real-time co-editing needs a server that owns the document's current state. In practice, that is something database-backed apps provide and file-based setups do not. With files, collaboration means one person edits at a time, or you merge changes afterward.
What you get in return
Your notes are ordinary files. A shell one-liner can search them, rename them in bulk, or add a tag to a batch. A script can generate a daily note from a template. A backup tool that copies files backs them up, with no special export step. And any editor you adopt later can open them, because there is no format to decode.
What a database costs you
You leave only through the export
Your notes exit the app through its export function, and the vendor writes that function with no obligation to make it complete. When you evaluate a database-backed app, the export is the part to test, because it is the part you will depend on at the exact moment you have stopped trusting the app.
Things to check in an export:
Links between notes. Do they come out as working links, as plain text of the target's title, or as an internal ID that means nothing outside the app?
Attachments. Are the actual files in the export, or does each note keep a reference to a location that no longer exists?
Structure. Do nested pages, folders, and databases-within-notes keep their hierarchy, or flatten?
Metadata. Creation dates, edit dates, and tags can be dropped or written in a form no other tool reads.
An export that loses any of these can still be usable. An export you have not opened in a plain text editor is one you know nothing about.
The vendor's lifespan is your notes' lifespan
Pricing can change, the company can be acquired, the product can be discontinued. If the notes live on the vendor's servers, your access ends when theirs does. If they live in a local database file, you still depend on the app to decode a format that is not documented for anyone else. The five-year threshold in the verdict is not a prediction about any particular vendor; it is a way of asking whether you are comfortable betting that this app, on these terms, will still be the right tool at the far end of that window.
Sync is included, on their terms
Cross-device sync works out of the box, which is a genuine advantage. If that sync runs through the vendor's servers, your notes pass through those servers and are reachable across devices only while they are up.
What you get in return
Because the app controls the whole stack, the features that are awkward with files are polished here: backlinks that update instantly, a capture button on your phone that drops a thought into the right place, and a document that two people can edit at once without a merge step. If those are the things you would actually use daily, they are worth a great deal.
How to decide
- How long will these notes matter? If you expect to still be reading them more than five years from now, choose files. The cost of a bad export grows with every year of accumulated notes.
- Do you want to script over them? Templating, bulk renames, custom searches, feeding notes into other tools. If yes, choose files. Scripting against a database means going through whatever export or API the vendor offers.
- Otherwise, weigh what you would use. If linking, collaboration, or mobile capture would shape how you work more than portability would, choose a database. Then run an export early, before you have much in it, and open the result in a text editor. If what comes out is thin, you have learned that while switching is still cheap.
Who should skip this decision
Your notes are short-lived. Meeting notes you delete when the project ends, a scratchpad you clear weekly. Portability of things you will not keep is not worth optimizing. Use whichever option is already on your machine.
Your team has already standardized. If the notes are shared work product, the team's tool wins over your personal preference. Ownership matters less for notes you do not own alone, and collaboration is a database strength anyway.
You are already happy. If your current system works and you have never hit a wall, do not migrate for the principle of it. Migration has its own costs, and "I could own the files" is not a problem until it is.
The next step
Open your current note system and put it in one of the two buckets. If it is a database, run an export today and open the result in a plain text editor. What survives that trip is what you actually own.