Notion Export Database to CSV: Relations Become URLs

Somebody exports the project tracker, opens the CSV in Excel, and the Owner column is fine, Status is fine, and the Client column is a list of web addresses. Each cell holds notion.so followed by 32 hexadecimal characters. Nobody typed those. In the workspace they were company names you could click.

This is not a defect and Notion does not treat it as one. The behaviour is written down, in a one-sentence FAQ answer near the bottom of a page most people open for an unrelated reason, and the same sentence tells you the file cannot be read back in.

Three formats, and the dropdown decides more than the file extension

The export dialog offers PDF, HTML, and Markdown & CSV. It looks like a choice about what you want to read afterwards. It is a choice about which parts of the database survive.

The third option carries a mechanic worth knowing before you pick it: a full-page database comes out as a CSV, every subpage inside it comes out as its own Markdown file alongside, and callout blocks are written as HTML because Markdown has no equivalent for them.

One more line worth knowing before you commit to PDF: "If a PDF export fails, Notion will instead export as HTML." A failed run that quietly succeeds in a different format is something to notice while the account is still open, not two months later.

These are separate runs from the same menu, and nothing says you have to pick one. The teams that end up with a usable archive generally take Markdown & CSV for the structure and HTML for the conversation, and treat the pair as the deliverable.

A relation exports as a URL, and Notion will not read it back

The sentence that matters sits in the FAQ block of the relations and rollups page: "When you export a relational database as a CSV file, the relation properties will export as plain text URLs. For now, you can't re-import that CSV back into Notion to re-establish the relations with other databases."

Read both halves. The first is a downgrade you can live with. A URL still identifies the page it points at, and the page identifier sits right there in the address, so a relation column is not information-free. The second half is the one that costs money. Whatever you were planning to do with that CSV, rebuilding the graph inside Notion by uploading it is not on the list.

Those addresses keep resolving for exactly as long as the workspace does. After the subscription lapses they are a column of dead links carrying identifiers that no longer point at anything you can open. Which is why the relation column is worth converting while both ends still exist: on a database you actually care about, open each linked page and write its title into a plain text column beside the URL. A hundred rows of that is an afternoon. A hundred rows of it after cancellation is not available at any price.

There is a second trap in the same feature, and it catches the careful people. Duplicating a database inside Notion looks like the cheapest possible backup. Notion's own FAQ explains what it actually does: duplicate the Customers database and the copy "will not show as a relation in the Items database," because "upon duplicating the Customers database, we convert the relation from a 2-way sync to a 1-way sync." The copy exists, every row is present, and the schema is not the schema you copied. The failure is silent from the side you are looking at: open the duplicate and its relation column still reads correctly, because what broke is what the other database can see. An in-app duplicate is a convenience copy. It should never be counted as an export.

Rollup, formula, and the columns no import can re-create

Notion's import page publishes a short list under what does not import for CSV, and it is unusually direct:

• "A new CSV import can't create new rollups or formulas (you'll need to rebuild these in Notion after import)."
• "A new CSV import can't create new relations. If you add a CSV to an existing database, you can map a CSV column to an existing relation property."

So the round trip is asymmetric by design. On the way out you get numbers. On the way back in you get a text column where a calculation used to be, unless the destination database already has the relation property built and you map to it.

What leaves in the CSV is the answer. The rule that produced it lives in the schema, and the schema is not in the file — a split visible in Notion's own API, where the expression and the computed result are two different requests. That much is true of most products, and the general version of the argument covers it. What is specific to leaving Notion is the sentence above: no import puts the rule back.

So capture the rules separately before the account closes. Every formula expression as text, and for every rollup the three things that define it — the function, the relation property it walks, and the property it rolls up. A screenshot of each property editor is a poor archive and an excellent one compared with nothing, and it costs about a minute per column. This is the same class of problem as an attachment column that turns out to hold links rather than files: the export is honest about what it contains, and what it contains is thinner than what you were looking at on screen.

One database row lands in two files, joined by a filename

Here is the mechanism behind the phrase people search for after their first export. A Notion database row is two things at once: a set of properties and a page. The Markdown & CSV export splits them. Properties go into the CSV as a row. The page body — the notes, the nested toggles, the checklist somebody actually used — goes into its own Markdown file, one per subpage, in a folder beside the CSV.

Nothing joins the two except the file name. Open the CSV on its own and every row looks like a record with no content in it, which is precisely why the databases feel flat. The content is in the folder sitting next to the file.

That join is also the fragile part, and on Windows it has a documented failure mode: nested subpage folders push the combined path past the 260 character limit, and past it the ZIP will not open or extract at all. Notion offers two ways round it and both cost something. Unchecking Create folders for subpages shortens every path by discarding the nesting — which was the only surviving record of where each page sat. Extracting with a tool that tolerates long paths keeps the folders and costs an extra step. If your hierarchy carries meaning, take the extra step. Deciding that deliberately beats discovering it when Explorer refuses the ZIP at eleven at night with a renewal three days out.

The current view or the default view, and that is all

Two limits on the export page get skipped because they read like footnotes.

"When exporting a database, you can only choose between the current view and the default view. Exporting all views at once isn't supported."

"At this time, you can't export a Form view of a database. Try exporting your questions and responses from Table view instead."

Views are usually the part somebody built. Filters, sorts, groupings, which properties are visible in which context — that configuration is the accumulated product decision of a year of use, and there is no documented path for it to leave. Write the important ones down before you go, in whatever plain form you like: view name, filter conditions, sort order, visible properties. Four lines each, and it only has to be good enough for a person to rebuild from.

The immediate operational point is blunter. Because the export follows a view, and views are routinely filtered, the row count in your CSV is not automatically the row count in your database. Check it. Switch to an unfiltered view, export, then compare the number of data rows in the file against the count Notion shows on the database itself. If they differ, you exported a subset, and what you are holding is a report rather than a backup.

The plan you are on decides which of these you can run

Four gates sit on the export button itself, and they are unpleasant to meet on the last afternoon.

• Include subpages on the PDF path is a Business and Enterprise feature.
• Enterprise workspace owners can switch exporting off entirely, under Settings, then Security, then Disable export. Teamspace owners can do the same for a single teamspace.
• A guest needs Full access to a page or database to see the export option at all.
• The admin API route for starting a workspace export on a schedule is in beta, on the Enterprise Plan, and needs an organisation owner to set up an admin bot and token first.

A fifth rule decides the contents rather than the permission. A workspace export contains only what the person who ran it could already see, so private pages belonging to other users are simply absent, and teamspace settings can hold back more on top of that. Enterprise admins can grant themselves access to specific pages through content search so that later exports include them, which is a thing to do in week one rather than on the last afternoon.

The gap this leaves is invisible in the resulting ZIP: right file, right format, plausible size, and no indication of what was never eligible. If the workspace holds private pages the business depends on, those owners run their own export, or hand over access, before anybody cancels.

Thirty hours to build, seven days to download

Two numbers set the calendar for the whole exercise, and both are on the export page.

An export "can take up to 30 hours to process, depending on the size of the workspace." The download link arrives by email and "will expire after 7 days." If the account has email notifications switched off, the link goes to the in-app inbox instead — a small detail that has stranded people who spent two days watching the wrong place.

Put those against a renewal date and the arithmetic is unforgiving. A workspace expiring on 30 September wants its export started around 20 September at the latest: up to thirty hours to build, a seven-day window that has to close before the account does, and room for one failed attempt. Notion documents that large workspaces sometimes error out, and the workaround it gives is manual — go to each top-level page, export as Markdown & CSV or HTML with Include subpages switched on, and repeat for every top-level page worth keeping. Budget for that rather than assuming the one-click path works at your size.

Two related facts belong in the same set of notes. Notion does not offer scheduled automatic backups; asked directly, the help centre answers "Not at the moment." And deleted pages sit in Trash for 30 days by default, with Enterprise workspace owners able to set anything from one day to ten years. If somebody tidied up ahead of the migration, thirty days is the window in which that tidying is still reversible.

One more, for anyone planning to pull attachments through the API rather than out of the ZIP. A Notion-hosted file object returns a URL "valid for one hour," carries an expiry timestamp, and the documentation says not to cache or statically reference it. External links added to a files property behave differently: those "never expire and will always be returned as-is." A spreadsheet full of signed URLs is worthless by lunchtime. The bytes are the archive, which is the same conclusion that governs keeping a retired system readable in general.

An hour on one database tells you what the whole move costs

The whole exercise fits in an hour if it happens early, and does not fit at all if it happens late.

1. Pick the smallest database carrying a relation, a rollup and a formula. Note its row count.
2. Switch to an unfiltered view. Export it as Markdown & CSV. Export it again as HTML.
3. Open the CSV. Count data rows against step one. Confirm the relation column holds addresses, and check whether a row linked to several pages produces several addresses in one cell — that detail shapes any script you write later.
4. Open the folder beside the CSV and find the Markdown file for a row whose page body you recognise. That filename join is what you will be relying on in three years.
5. Capture the schema by hand: every formula expression as text, and for every rollup the function, the relation property and the rolled-up property.
6. Import the CSV into a scratch destination, wherever you are going. Watch the derived columns land as plain text. Decide now who rebuilds them, and how many hours that is across the real workspace.
7. Only then run the workspace export, with the seven-day link window sitting entirely inside what is left of the subscription.

Step six is the one people skip, and it is the only step that produces a number you can plan against. Notion is explicit that exported content cannot simply be uploaded back to recreate a workspace. A scratch import on one database turns that sentence into an hours estimate for your own data, which is what the decision actually needs.

Verified against Notion documentation on 14 September 2026. The format behaviour, the plan gate on PDF subpages, the view limitation, the 30-hour and 7-day figures and the Windows path FAQ come from Export your content. The relation quotation and the duplication behaviour come from Relations and rollups. The CSV import limitations come from Import data into Notion, the absence of scheduled backups from Back up your data, and the Trash defaults from Custom data retention settings. Formula and rollup value behaviour is from the property object reference, and the one-hour signed URL from the file object reference. Notion revises these pages without notice, so re-read the two help pages before you rely on a date-sensitive step.