Shopify to Snowflake: How to Move Your Data

Moving Shopify into Snowflake gives you a shop's full commercial history somewhere it can be joined to everything else. Shopify's own reporting answers the obvious questions and stops at the boundary of the store, which is exactly where the interesting questions start: what a customer costs to acquire, whether discounting actually works, how returns erode a good month.

This guide covers the managed path with Airbyte. Two things shape the build: a missing scope removes a stream without telling you, and this data is full of customer personal information that a warehouse will happily expose to everybody.

Shopify to Snowflake at a glance:

Why move data from Shopify to Snowflake?

Two situations account for most of these pipelines.

The first is profitability rather than revenue. Shopify knows what was sold and nothing about what it cost to acquire the customer, fulfil the order or handle the return that followed. Putting orders beside advertising spend, shipping costs and support contacts is what turns a sales figure into a margin, and that only happens in a warehouse.

The second is multi-store consolidation, where several shops need reporting as one business. The choice of warehouse matters less than people expect, so if your organisation already runs on Google Cloud there is little reason to introduce a second platform and Shopify to BigQuery will serve you equally well. Snowflake earns its place here mainly through how it handles sensitive columns, which this data has plenty of.

What do you need before you start?

Four things, and the first determines what your dataset contains:

A custom app with the scopes your streams need. Shopify scopes access per resource, so read orders, read customers, read products and so on are separate grants. The Shopify source documentation lists which scopes each stream requires, and it is worth reading rather than guessing.

Your shop name, which is the subdomain. The portion before myshopify.com, not the domain customers type. This trips people up on stores whose public domain has been custom for years and whose original subdomain nobody remembers.

Snowflake objects and a role. A warehouse, database, schema and a role that can create tables. Give this its own schema, because the access controls you will want over customer data should not be entangled with whatever else lives in your warehouse.

A decision about who can see customer details. Orders and customers carry names, email addresses, phone numbers and delivery addresses. Most analysts need none of it, and deciding that before the first sync is considerably easier than retrofitting controls to a table people already query.

If your Snowflake account restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the network policy before you begin.

How do you build a Shopify to Snowflake pipeline in Airbyte?

Step 1: Match scopes to streams before you create anything

Write down the streams you need, look up the scope each one requires, and grant exactly those on the custom app. Do it in that order, because the failure mode runs the other way: a stream whose scope is missing does not error, it simply is not there, and a dataset that arrives without complaint looks complete. Checking the discovered streams against your list is the only moment this is cheap to catch.

Step 2: Configure the Shopify source

Click Sources in the left navigation, then New Source, and select Shopify, following adding a source. Supply the shop subdomain, credentials and start date. Rate limit warnings in the logs are normal for this connector and are not a sign that anything is wrong, so do not go hunting for a problem because of them.

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. Orders carry nested line items and Snowflake holds that structure natively, so there is no flattening to arrange on the way in.

Step 4: Create the connection and watch the bulk streams

Click Connections, then New connection, select your streams and a sync mode. The connector uses three different Shopify APIs depending on the stream, and streams served by GraphQL Bulk are the ones that occasionally stall on a large store. The bulk job checkpoint setting is the lever for that, and knowing it exists saves an afternoon.

Then apply your access controls before anybody is given the schema, because the first query somebody runs sets the expectation for what they can see.

Why would a stream simply not be there?

Because Shopify grants access per resource and the connector reports what it can reach rather than what you hoped for. An app without the customers scope produces a dataset with no customers stream, and nothing in the sync result says so. The pipeline succeeded, which is true and unhelpful.

This bites hardest on stores where the app was created by somebody else, months earlier, for a different purpose. Scopes granted then reflect that purpose, and nobody thinks to revisit them because the pipeline appears to work. The symptom arrives much later as an analyst asking why a join returns fewer rows than expected.

The defence is a list and a comparison. Write down what you expect, check it against what discovery returns, and investigate any gap before building anything on top. Granting broad scopes to avoid the problem is tempting and wrong, since this app can read every customer record in your store and the fewest scopes that work is the right number.

How should Snowflake hold your customers' personal data?

Behind masking policies, applied before anybody gets access. Shopify's orders and customers streams carry names, email addresses, phone numbers and full delivery addresses, and in a warehouse these become ordinary columns that any analyst with access to the schema can read. That is a meaningful change in exposure from Shopify, where seeing customer records requires a login and a role.

Snowflake gives you two tools worth using here. Masking policies apply at the column level, so an analyst can group by country or count repeat purchasers without ever reading an email address, while a support-facing role sees the real value. Row access policies handle the other dimension, restricting which records a role sees at all, which matters if regional teams should only work with their own market's customers.

Use TRY_CAST while you are modelling this data, because store data is messier than you expect. Phone numbers held as text, quantities entered by hand through an admin screen, values from an app that wrote something unusual years ago: a plain cast raises and stops the query, whereas TRY_CAST returns null and lets you find the offending rows deliberately rather than by interruption.

Frequently asked questions

Why is a stream missing from my sync?

Almost certainly a missing scope. Shopify grants access per resource and an ungranted one removes the stream without raising an error, so compare what discovery returned against what you expected.

Should I worry about rate limit warnings in the logs?

No, they are normal for this connector and their presence does not indicate a problem. Judge the sync by whether it completes and whether the data is right.

A bulk stream seems stuck. What now?

Streams served by GraphQL Bulk can stall on large stores, and the bulk job checkpoint setting is the intended remedy. Adjust it rather than assuming the store is too big.

What exactly is the shop name?

The myshopify subdomain rather than your public domain. Stores with a long-established custom domain often have to go and look this up.

Can I do this without writing code?

The pipeline, yes. Masking and row access policies are SQL, and given what this data contains they are not an optional extra.

Get your Shopify data into Snowflake

List your streams, grant exactly the scopes they need, and check discovery against that list, because a missing scope produces a missing stream and no warning. Ignore the rate limit lines in the logs. Reach for the bulk checkpoint setting when a large store stalls. And apply masking and row access policies before the schema is handed out, since a warehouse makes customer records far easier to read than Shopify ever did.

Airbyte's connector catalog includes 600+ pre-built connectors, so store data can sit beside the costs that determine whether it was profitable. For the same source into a lakehouse, see Shopify to Databricks, and for another customer-rich system into the same destination, Salesforce to Snowflake.

Start syncing now →