Shopify doesn't give you a database, so every route here goes through an API. That single fact decides the cost, the speed and the failure modes of all of them.
On PrestaShop, WooCommerce or Magento you can point something at MySQL. Shopify is API-only: you get the Admin API, and that's the whole surface. So the question isn't which database to read, it's how to move a store's history through an API without spending a week on pagination and rate limits.
The REST Admin API is paginated and rate-limited, and pulling several years of orders page by page is slow enough that people give up and pull only recent data. The right tool for volume is the GraphQL Bulk Operations API: you submit a query, Shopify runs it in the background and hands you a JSONL file to download. It's genuinely good, and it's also a job queue you now have to poll, retry and monitor.
Then there's shape. The API returns nested JSON — an order carries its line items, discounts, tax lines and fulfilments inside it. BigQuery can store that as nested fields, but every downstream query has to unnest it, and most people end up flattening line items into their own table anyway. That modelling is the actual work, exactly as it is on a MySQL store.
All three work. They differ in what they cost you — in money, in maintenance, and in load on the database your customers are using right now.
A hosted service with a Shopify source that lands orders, products and customers in BigQuery on a schedule.
A GraphQL bulk query per object, polled to completion, JSONL downloaded and loaded into BigQuery on your own cron.
The model we run for MySQL stores — an isolated, verified copy you query directly or load onward. Shopify needs a dedicated API connector, which is in development.
In Shopify admin, Settings → Apps and sales channels → Develop apps. Grant read access to orders, products and customers, and nothing else. The token this gives you is the only credential in the whole pipeline, so scope it tightly.
Use the GraphQL bulkOperationRunQuery mutation for orders, products and customers separately. Shopify queues each one and runs it against the whole dataset — no pagination on your side.
Check the operation's status until it completes and Shopify gives you a signed URL to a JSONL file. Nested children arrive as their own lines with a parent id, which is what you'll join on.
bq load handles JSONL directly. Land it raw, then build views that flatten line items into their own table — one row per line, joined to the order. Every useful revenue and product query hangs off that shape.
Worth asking before you build anything. A warehouse is the right tool for some of these situations and overkill for the rest.
No. BeQuery clones a store's MySQL database, and Shopify doesn't have one to connect — it's API-only. A dedicated Shopify connector is in development and there's an early-access list you can join. Until it ships, the honest answer for Shopify is a managed ETL connector or the Bulk Operations API, which is why both are described above in more detail than our own column.
It works and it's the obvious first attempt, but it's slow under rate limits and it's the part that breaks quietly: a job that takes hours is a job that fails halfway. Bulk Operations exists precisely because exporting a full store through paginated REST calls is the wrong shape for the problem.
No. The Admin API, custom apps and Bulk Operations are available on standard Shopify plans. What varies by plan is the depth of Shopify's own built-in analytics — which is often what sends people looking for a warehouse in the first place.
BeQuery works today on stores with a MySQL database — PrestaShop, WooCommerce and Magento. Shopify is API-only, so it needs a dedicated connector, and that's in development. Put your email down and we'll tell you the day it opens.