Notion to Databricks: How to Move Your Data

Moving Notion into Databricks gives you somewhere to analyse a workspace that has quietly become a system of record. Notion is pleasant to write in and offers very little when somebody asks which projects stalled, how documentation coverage has changed, or what is no longer being maintained.

This guide covers the managed path with Airbyte. Two things shape the build: a recent connector version renamed a central concept and changed the streams you get, and page content arrives as a deeply nested tree that this destination is unusually good at handling.

Notion to Databricks at a glance:

Why move data from Notion to Databricks?

Two situations account for most of these pipelines.

The first is working with the content rather than the metadata. Once a workspace holds thousands of pages, the interesting work involves the text itself: finding duplicated guidance, feeding a retrieval layer, or classifying documentation by topic. That is transformation and modelling work, which is what a lakehouse is for.

The second is joining workspace activity to delivery data, setting documentation against the projects it describes. If the aim is straightforward reporting over page properties in typed columns, a warehouse is simpler to operate and Notion to BigQuery asks considerably less of you than a lakehouse will.

What do you need before you start?

Four things, and the first is done in Notion rather than in Airbyte:

An integration, with pages shared to it. Notion access is opt in, so a page the integration has not been given is simply not there. Sharing a parent page passes access down its children, which makes top-level sharing the efficient approach. The Notion source documentation covers the setup.

Awareness of the version 4.0.0 rename. What the connector called databases became data sources. A new pipeline simply uses the new names; an existing one has downstream code referring to names that no longer exist.

Permission to create Volumes in Unity Catalog. Staging goes through Avro files written into a Volume, which is separate from being able to create tables and worth requesting early where Unity Catalog is centrally administered.

A view on what page content is for. Reconstructing readable text from the block tree is real work, and it is worth doing only if somebody will use the text rather than just the page properties.

If your workspace restricts traffic by IP, add the Airbyte Cloud IP addresses to the allow list before you begin.

How do you build a Notion to Databricks pipeline in Airbyte?

Step 1: Share pages from the top down

Decide which parts of the workspace are in scope, then share those parent pages with the integration and let access flow downwards. Doing it page by page is how teams end up with a dataset missing sections nobody can identify, because a page that was never shared produces no error and no gap anybody can see. Write down what you shared, since the dataset's boundary exists only in Notion's sharing settings.

Step 2: Configure the Notion source

Click Sources in the left navigation, then New Source, and select Notion, following adding a source. Supply your credentials and a start date, then select streams. If you have used this connector before, check the stream names against what your downstream code expects rather than assuming they match.

Step 3: Configure the Databricks destination

Click Destinations, then New Destination, and select Databricks, following adding a destination. Supply the workspace details, warehouse or cluster, catalogue and schema. Blocks arrive nested and Spark reads that natively, so let the structure land intact rather than arranging any flattening on the way in.

Step 4: Create the connection and check the boundary

Click Connections, then New connection, select your streams and a sync mode. After the first sync, compare the pages you received against the areas you intended to share, because that comparison is the only way the sharing boundary becomes visible. Daily is ample for a documentation workspace.

Then build the silver layer, because the landing tables are faithful to Notion's structure and that structure is not what anybody wants to query.

What changed in version 4.0.0?

The concept called databases became data sources, and the streams changed accordingly. Notion's own terminology moved, and the connector followed, which is the right decision and a breaking one for anybody with code referring to the old names.

For a new pipeline this is simply a naming note. For an existing one it is a migration, and the failure is downstream rather than in the sync: transformations, dashboards and notebooks referencing the old stream names stop resolving, while the pipeline itself reports success. That combination makes it look like a warehouse problem rather than a connector upgrade.

If you are upgrading, search your workspace for references to the old names before the version changes rather than after. And if you are building fresh, insulate yourself by having everything downstream read views rather than the landing tables directly, so the next rename is one view definition to update instead of a hunt through everybody's notebooks.

How should Databricks hold a page's content?

As the tree it is, then reassembled above. A Notion page is not a document with a body field; it is a hierarchy of blocks that can nest up to thirty levels deep, where a toggle contains a list containing a table containing more text. Reading a page means walking that tree, and the structure is the content rather than an encoding of it.

This is where the destination genuinely earns its place. Spark handles nested structures natively and walking a hierarchy is ordinary work in a notebook, whereas reconstructing the same page in a relational warehouse means a recursive query that nobody enjoys maintaining. The raw record also lands beside the typed columns, so a block type nobody modelled is still recoverable later.

Build a silver table holding one row per page with its text assembled in order, which is the shape every downstream use actually wants, whether that is search, classification or feeding a retrieval layer. Keep the block tree in bronze underneath, and decide deliberately which block types contribute text, since code blocks, embeds and databases inside pages are not all things you want concatenated into a paragraph.

Frequently asked questions

Why are some pages missing?

They were not shared with the integration. Notion access is opt in, and an unshared page produces no error, so share parent pages and let access flow down.

My existing transformations broke after an upgrade.

Version 4.0.0 renamed databases to data sources, so downstream code referring to the old stream names no longer resolves while the pipeline itself keeps succeeding.

Do I need to flatten blocks before loading?

No. Spark reads nested structures natively, so let the tree land intact and reassemble page text in a silver table where the logic is visible.

How deep does the nesting go?

Up to thirty levels, which is why reconstructing page content is a real piece of work rather than selecting a column.

Can I do this without writing code?

The pipeline, yes. Assembling page text from the block tree is modelling work, and it is the part that makes the content usable for anything.

Get your Notion data into Databricks

Share parent pages with the integration and record what you shared, because the dataset's boundary lives in Notion's sharing settings and is invisible from the data. Check stream names if you are upgrading, since version 4.0.0 renamed databases to data sources and breaks downstream code quietly. Then let the block tree land intact and assemble page text in a silver table, which is the job Spark makes straightforward and a relational warehouse does not.

Airbyte's connector catalog includes 600+ pre-built connectors, so workspace content can be analysed alongside the work it documents. For the same source into a warehouse, see Notion to Snowflake, and for another workspace tool into the same destination, Airtable to Databricks.

Start syncing now →