Shopify to BigQuery Connectors Compared (2026)

⏱ 13 min read

You cannot query your Shopify database directly. Shopify hosts your store and does not expose the underlying database, so there is no SQL you can run against your live orders, customers and refunds. You stay responsible for that customer data and how it is used, but analysing it next to ad spend, 3PL costs and return rates means copying it somewhere you control. For most growing brands, that place is Google BigQuery.

The Shopify BigQuery connector you pick decides three things: what the pipeline costs each month, how much engineering time it eats, and how clean the data lands. In 2026 the shortlist changed, because Google shipped its own native connector. This guide compares all five routes for moving data from Shopify to BigQuery, the native connector, Fivetran, Airbyte, no-code tools and a custom build, with current pricing and the trade-offs that decide which one fits your store.

What a Shopify to BigQuery Connector Actually Does

A Shopify BigQuery connector extracts objects from Shopify’s Admin API, then loads them into BigQuery tables on a schedule. This is ELT, extract and load first and transform later, not the older ETL pattern where you clean data before it lands. The connector handles the moving. It does not handle the meaning.

That distinction is where most Shopify data projects quietly fail. Raw Shopify objects arrive nested and unnormalised, shaped like API responses rather than analytics tables. Orders land with line items buried inside arrays and money fields split across currencies. Here is the full path the data actually travels, and where the connector’s job starts and stops.

The Five Ways to Move Shopify Data Into BigQuery

There is no single best Shopify BigQuery connector. The right choice for your Shopify data pipeline depends on data volume, in-house engineering, and how much you value a predictable bill. Here is the shortlist at a glance before we price each one properly.

Google’s Native Shopify BigQuery Connector, the 2026 Change

The biggest shift this year is that Google added a native Shopify connector to the BigQuery Data Transfer Service, alongside new preview connectors for Klaviyo, HubSpot and Mailchimp. You create a transfer directly in BigQuery, pick your Shopify objects, set a schedule, and run backfills, with no third-party ETL tool in the middle. Google’s own Data Transfer Service update confirms the launch.

The pricing is the headline. The transfer itself is free while the feature stays in Preview, per the Google Cloud documentation. You still pay the standard BigQuery storage and query costs once the data lands and you start analysing it, so “free” covers ingestion, not the warehouse. Preview terms and behaviour can also change when the connector reaches general availability, so treat today’s setup as a Preview snapshot rather than a locked-in price.

Object coverage is broad, and it pays to use Google’s exact object names so you do not build a pipeline around something the connector does not load. Supported objects include, among others:

• Sales: Orders, OrderTransactions, Refunds, Returns
• Catalogue: Products, ProductVariants, ProductOptions, InventoryItems, PriceLists
• Customers and fulfilment: Customers, Companies, DraftOrders, Fulfillments, FulfillmentOrders
• Promotions: the Discounts objects (automatic and code discounts) and GiftCards
• Structure and meta: Locations, Metafield objects, Segments, Publications

A few objects come with conditions: GiftCards requires Shopify Plus, ProductResourceFeedbacks and the app subscription objects need a sales channel app, and the app-based and basic code discount objects need an app built with the Shopify CLI (as of October 2026). Abandoned checkouts are not on the list. The supported list shifts as the connector matures, so check the official supported-objects list before you design a schema rather than assuming an object is present.

How to Connect Shopify to BigQuery With the Native Connector

Setting up the native transfer takes a short checklist on both sides, per Google’s setup guide (as of October 2026):

1. In Shopify, create a custom app for the store and grant it the Admin API read scopes for every object you plan to load. Without the matching scope, that object cannot be transferred.
2. Note the shop name (the part before .myshopify.com) and the app’s client ID and client secret.
3. In Google Cloud, enable the BigQuery Data Transfer Service, create the destination dataset, and make sure the person setting it up has BigQuery Admin or equivalent permissions.
4. Create a transfer with Shopify as the source, select the objects, choose a repeat frequency or on-demand runs, and save.
5. Trigger a backfill run for the history you need, then compare row counts with Shopify admin before anyone builds a report on top.

The honest trade-off: the native connector is the simplest and cheapest way to move data from Shopify to BigQuery in 2026 while the transfer is free. It does not transform data, it does not auto-repair schema changes the way a managed ETL tool does, and it does not solve the modelling work that comes after. For lean teams and early data projects, that is often an acceptable trade.

Native vs Third-Party Shopify BigQuery Connector

The question most teams now ask is not which ETL vendor to use, but whether they need one at all. The native connector and third-party tools solve the same extract-and-load step, but they differ on everything around it.

A practical rule: start native when Shopify is your main source, BigQuery is your only warehouse and you can live with Preview terms. Go third party when you need contracted support, several sources in one tool, or a destination other than BigQuery. Many teams combine both: native for Shopify, a paid tool only for the sources Google does not cover.

Fivetran vs Airbyte for Shopify

Once you outgrow the native connector, the real Shopify BigQuery connector decision for most brands is Fivetran vs Airbyte for Shopify. They sit at opposite ends of the control spectrum. Fivetran is fully managed and prices by the row. Airbyte is open-source at heart and prices by volume or by your own infrastructure. The mechanics matter more than any headline rate, so here is how each actually bills a Shopify store.

How Fivetran Prices Shopify Data

Fivetran bills on Monthly Active Rows, the distinct rows inserted, updated or deleted in your destination each month. A row counts once no matter how often it changes, so the bill tracks how much your data changes rather than how often you sync. Fivetran’s pricing is consumption-based with a per-connection minimum, and their pricing page publishes a live calculator and worked examples rather than one flat rate. Model your own connectors there, because a Shopify store’s MAR depends heavily on how many rows churn each month. Two published details matter for smaller stores (as of October 2026): the Free plan covers up to 500,000 MAR, and on paid plans a 5 dollar base charge applies to each standard connection with between 1 and 1 million MAR in a month.

What you buy for that price is genuine no-ops. Fivetran handles Shopify’s schema drift automatically, adding columns in BigQuery when Shopify changes a field, and manages the API rate limits for you. It also ships pre-built dbt models for common Shopify transformations like order line items and daily revenue. If you never want to think about the Shopify data pipeline again, that is what you are paying for.

How Airbyte Prices Shopify Data

Airbyte comes in two very different forms. Airbyte Core is the open-source, self-managed edition and is free to license. Self-hosting is not zero cost, though: you add the infrastructure to run it plus the engineering time to deploy and maintain it, and how much that adds up to depends entirely on your deployment, data volume and team. Size it as a real line item, not as free.

Airbyte Cloud is the managed edition. As of October 2026, Airbyte publishes a Standard plan from 20 dollars a month with 5 credits included and volume-based billing, a Plus plan with fixed credit packages from 189 dollars a month, and Pro and Enterprise tiers priced by capacity. Sync frequency is tied to the tier as well: hourly at most on Standard, every 15 minutes on Plus, and every 5 minutes on Pro. Check Airbyte’s pricing page for the current rate card, since the tiers and rates change.

Which One Fits Which Team

The choice comes down to whether you are buying away engineering work or buying control. This table maps the differences most teams weigh.

No-Code Connectors for BI-First Teams

Not every team wants an ETL platform. Some just need Shopify numbers in Looker Studio or a warehouse feeding a dashboard, without a data engineer in the loop. That is where a lighter no-code Shopify BigQuery connector fits, and several are built specifically for the Shopify to Looker Studio and Sheets workflow.

The appeal is speed and a predictable bill. This is the practical shortlist and where each one earns its place:

The trade-off is depth. No-code tools usually expose fewer objects, give you less control over schema and history, and get weaker as your data model grows. For a store that mainly wants clean dashboards and cross-channel blending, that is a fair exchange. For a finance-grade data foundation, it is usually a stepping stone rather than the destination.

Fivetran vs Skyvia vs Airbyte

These three get compared because they cover the same Shopify to BigQuery replication job at very different depths. Skyvia is a cloud data platform where a Shopify replication is configured in a visual wizard, which suits a marketing or BI team without engineers. Fivetran is the managed, hands-off end with the strongest schema drift handling and ready-made dbt models. Airbyte sits between them on Cloud and becomes the most flexible option when self-hosted. Skyvia’s own Shopify to BigQuery page states that pricing depends on features and data volume, so compare all three on a quote for your real row counts, not on headline plans.

Building Your Own Shopify Data Pipeline

A custom Shopify data pipeline gives you total control and no per-row tax, and it is the route for teams with unusual objects, strict data residency needs, or the scale to make ETL fees hurt. It is also the route where Shopify’s API design decides whether your pipeline is stable or a stream of failures. This is the expert section, and the constraints are real.

Shopify’s GraphQL Admin API measures load as a calculated query cost, drained from a leaky bucket measured in points per second. Each field carries a cost:

• Scalar and enum fields (id, name, email): 0 points
• Objects and interfaces: 1 point each
• Connections: cost set by the first or last argument, the page size you request, times the cost of the objects inside
• Mutations: 10 points

The ceiling depends on plan: 100 points per second on Standard, 200 on Advanced, 1,000 on Shopify Plus, and 2,000 (20X standard) on Commerce Components, per Shopify’s API rate-limit documentation. On top of that, a single query is capped at 1,000 points on every plan, so a deeply nested request can fail with a THROTTLED error no matter how much bucket you have. That tenfold jump from Standard to Plus is one of the less visible arguments in the Shopify Plus vs Shopify decision for data-heavy brands.

For large extraction, the Bulk Operations API is the tool that sidesteps the interactive limits. It runs your query asynchronously on Shopify’s infrastructure and hands back a single JSONL file, so you skip manual pagination and client-side throttling. Shopify sets no fixed record threshold for using it; the trigger is query complexity and how much latency you can accept. Since the 2026-01 API version, an app can run up to five bulk query operations at once per shop, up from one, which lets you parallelise large pulls.

Shopify Webhooks to BigQuery for Near-Real-Time Data

Scheduled pulls are fine for reporting, but some uses, such as live order dashboards or stock alerts, need data within minutes. For those, flip the direction: instead of polling Shopify, let Shopify push events. Shopify can deliver webhooks straight to a Google Cloud Pub/Sub topic, which Shopify’s documentation recommends as a cloud delivery method, and a Pub/Sub BigQuery subscription can write each message into a table without a server in between.

Two caveats keep this honest. Webhooks are event notifications, not a replicated database, so a missed or delayed event leaves a gap unless you reconcile against a scheduled full or incremental load. And webhook payloads arrive as raw JSON, so they need the same modelling as any other source. Treat webhooks as the fast lane on top of a reliable batch pipeline, never as its replacement.

One planning point: Shopify made the REST Admin API legacy as of 1 October 2024, and since 1 April 2025 every new public app must be built on GraphQL, per the Admin API documentation. Shopify has not announced a single shutdown date for all existing REST integrations, but the direction is set, so budget any older custom app for a GraphQL rebuild. The real work is not rewriting queries, it is re-architecting your queue around calculated query cost instead of simple request counting. If you would rather not own that, this is where custom Shopify apps built and maintained by a team earn their keep.

Shopify to BigQuery Cost, Side by Side

Pulling the pricing together, each Shopify BigQuery connector has an entry point and a factor that drives the bill up, and those matter more than any single quoted number. Store-specific totals depend on how much your data changes, so treat these as the cost model, not a final invoice.

There is a platform point worth stating carefully. Because Shopify hosts your store and does not expose the database, getting your own data out always costs something, in connector fees or engineering. That is a real constraint, but it is not proof that another platform is cheaper: a self-hosted stack still needs its own extraction, infrastructure, maintenance and modelling, and any cost comparison only holds when you match data volume, SLA and requirements on both sides. If you are still choosing a platform, our take on Shopify vs WooCommerce weighs the wider trade-offs.

What to Do After the Data Lands

This is where most connector guides stop and most data projects stall. Raw Shopify objects in BigQuery are not analytics-ready. They are nested API tables that need transformation, modelling and a semantic layer before any query returns a number your finance team will trust. The Shopify BigQuery connector question is solvable in an afternoon. The modelling question decides whether the warehouse earns its cost.

The work after ingestion is fairly consistent across stores, and it usually runs in this order:

1. Deduplicate and unnest the raw API tables.
2. Build clean models for orders, line items and customer lifetime value.
3. Reconcile refunds and multi-currency money fields.
4. Define one source of truth for metrics like net revenue.

Teams typically reach for dbt here, and Fivetran’s pre-built models give a head start if you went that route. Without this layer, you have an expensive data dump, not a data foundation.

Once the data is trustworthy, it feeds the decisions that pay for the whole exercise: joining order data to ad spend to see real channel profitability, building retention and lifecycle marketing segments on hard numbers, and grounding your wider Shopify growth strategy in margin rather than gut feel. That payoff only arrives after the modelling, not after the load.

Joining Shopify Data With GA4 and Ad Spend in BigQuery

Shopify orders alone tell you what sold. The questions that justify a warehouse, which channel brings profitable customers and which campaigns only look good in their own dashboards, need behaviour and cost data next to the orders. In BigQuery that usually means three sources side by side.

Each GA4 export incurs BigQuery storage and processing costs, and the optional streaming export adds 0.05 dollars per GB, per Google’s export documentation (as of October 2026). Google says data starts flowing within 24 hours of linking, so link the property early: the export builds history from that point, which is why teams that link late end up with short GA4 tables next to years of Shopify orders.

The join is where most projects stumble. The GA4 export stores one row per event in a nested schema, while Shopify stores orders. The bridge is the purchase event’s transaction_id, which has to match the order identifier your tracking sends; check whether your setup sends the Shopify order ID or the order name before you write the join. With that in place you can compare GA4 attribution with the orders that actually shipped and were not refunded, and spot wasted ad spend on Shopify that platform dashboards hide.

The same joined tables are the evidence base for Shopify conversion rate optimization: funnel drop-offs by device and landing page from GA4, matched with real order values and return rates from Shopify. If you would rather hand the modelling and reporting to a Shopify agency, ask to see how they define net revenue and attribution before they build anything.

How to Choose Your Shopify BigQuery Connector

Match the Shopify BigQuery connector to your stage, not to a feature list. A pre-1M pound store and a 30M pound brand with a data team should not make the same choice, and paying for enterprise tooling too early is as wasteful as outgrowing a no-code tool too late.

Whatever you choose, the connector is the cheap and easy part of the project. The technical limits of Shopify’s API, the row-based economics of managed ETL, and the modelling work after the load are what separate a warehouse people trust from one they quietly stop opening. Pick the Shopify BigQuery connector that gets clean data from Shopify to BigQuery with the least drama, then spend your real effort on the layer that turns it into decisions. That measurement discipline is the same one that underpins solid technical SEO for Shopify: get the plumbing right, then act on what it tells you.