Confluence to Snowflake: How to Move Your Data
Move Confluence into Snowflake with Airbyte. What the five streams contain, the plan requirement for audit records, and how to model the joins.
Moving Confluence into Snowflake is a smaller and more specific job than it sounds, and being precise about what the connector actually returns will save you scoping a project around data it does not provide.
This guide covers the managed path: replicating Confluence Cloud into Snowflake with Airbyte. The connector exposes spaces, pages, blog posts, groups and audit records. That is a good dataset for documentation governance and access analysis, which spaces are alive, who can reach what, what changed and when. It is not a content pipeline for building a search corpus, and if that is your goal you will be happier knowing now than after the first sync.
Confluence to Snowflake at a glance:
Why move data from Confluence to Snowflake?
Two situations account for most of these pipelines, and one of them is the reason the project usually gets funded.
The first is documentation health. Which spaces have not been touched in two years, which teams are actively writing, how much of your wiki is effectively abandoned. Confluence can answer none of that well at an organisational scale, and a warehouse answers it in a single query.
The second is access auditing, and it is usually the stronger case. Confluence keeps audit records for a limited retention period, and the interface for querying them is not built for analysis. Landing them in Snowflake changes both facts at once: the history stops expiring, and it becomes something you can join against your identity provider, your HR data and your other audit sources.
What do you need before you start?
A short list, with one item that can stop the project entirely:
A Confluence Standard or Premium plan, if you want audit records. The audit stream is not available on lower tiers, and a connection configured to sync it simply will not return the data. Check the plan before scoping the project, because the audit stream is usually what justifies it.
An Atlassian API token. Along with your Confluence domain name and the email address of the account the token belongs to. Create it against a service account rather than an individual's login, because a connector that breaks when someone leaves the company is a connector that will break when someone leaves the company.
Confluence Cloud. The connector reads the Confluence Cloud REST API and is configured with a Cloud domain, account email and API token. Treat Cloud as the supported deployment.
Snowflake objects and a role. A warehouse, database, schema and a role with permission to create tables in that schema. Volume is genuinely not a concern here, so the smallest warehouse you have is almost certainly enough.
If your organisation restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list on the Snowflake side before you begin.
How do you build a Confluence to Snowflake pipeline in Airbyte?
Step 1: Create the service account and token
Create an Atlassian account for the integration, give it read access to the spaces you intend to replicate, and generate an API token from its account settings. Note the exact domain name of your Confluence instance and the email address on that account, since authentication uses the two together.
Step 2: Configure the Confluence source
Click Sources in the left navigation, then New Source, and select Confluence, following adding a source. Supply the API token, domain name and account email. Airbyte tests the connection immediately and then takes you to the new connection page.
Step 3: Configure the Snowflake destination
Click Destinations, then New Destination, and select Snowflake, following adding a destination. Supply the account identifier, warehouse, database, schema and role, along with your authentication method. Airbyte creates one table per stream and adds its own metadata columns alongside your data.
Step 4: Select every stream you need to join
Click Connections, then New connection, pick your source and destination, and choose a sync mode per stream. The important thing here is not to select content streams alone. Page and blog post records reference their space and their author by identifier, so the joins that make this dataset useful only work if spaces and groups come across alongside them. It is the single most common way this pipeline ends up half useful.
Why does this connector need no type conversion?
An unusual and genuinely pleasant property of this source: the Confluence Cloud REST API uses the same JSON Schema types Airbyte uses internally, so no type conversion happens on the way through. String is string, date-time is date-time, and nested objects and arrays arrive as they were.
In practice that removes a whole class of debugging. When something looks wrong in Snowflake you can be confident the connector did not silently coerce a value, which narrows the investigation to the API response or your own downstream model. On sources where the type mapping is lossy, that certainty is worth quite a lot.
It also means the modelling work is entirely yours to design rather than to reverse-engineer. Build views that resolve space and author identifiers to names, and point people at those rather than at the raw tables.
What can this pipeline not do?
It is not a content retrieval pipeline. The five streams describe spaces, pages, blog posts, groups and audit records, which suits governance and access analysis. If you want to build a search index or a retrieval corpus over your wiki's prose, this connector is not the tool and no amount of configuration makes it one.
It also cannot recover audit history you never captured. Confluence's own retention on audit records is limited, so the archive in Snowflake starts on the day your first sync runs. That is a good argument for setting the connection up before you need the history rather than after somebody asks for it.
And it will not tell you about Data Center or Server instances. The connector targets Confluence Cloud, so a self-managed Atlassian estate needs a different approach entirely.
Frequently asked questions
Why is my audit stream returning nothing?
The audit stream requires a Confluence Standard or Premium plan. On lower tiers the data is not exposed through the API at all.
Can I use this to build a search index over our Confluence content?
It is not what the connector is built for. The streams suit documentation governance and access analysis rather than content retrieval.
Does the connector work with Confluence Data Center?
It is built against the Confluence Cloud REST API and configured with a Cloud domain, Atlassian account email and API token. Treat Cloud as the supported deployment.
Which streams should I select?
Sync spaces and groups alongside pages and blog posts. Content records reference spaces and authors by identifier, so selecting content streams alone leaves you with keys you cannot resolve.
Can I do this without writing code?
Yes. The setup above is entirely UI-driven, from creating the source through to scheduling the connection. If you would rather manage pipelines as infrastructure, the same source, destination and connection can be provisioned from configuration files instead.
Get your Confluence data into Snowflake
This is a small, well-behaved pipeline with one plan-level prerequisite and one modelling requirement. Confirm you are on Standard or Premium if the audit stream is the point, sync the reference streams alongside the content ones, and use a service account for the token.
Airbyte's connector catalog includes 600+ pre-built connectors, so the same Confluence source can feed a lakehouse instead if that is where your governance data lives. See Confluence to Databricks for that pairing, and Genesys to Databricks for another source whose streams describe configuration rather than activity.
Integrate with 600+ apps using Airbyte
Move data from 600+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.