Getting WooCommerce data into BigQuery

Everyone hits the same two walls: WordPress stores orders in a shape no warehouse wants, and every pipeline you point at your shop reads from the same database serving your customers. Here's how the options actually compare.

Why this is harder than it should be

WooCommerce doesn't really have an orders table. An order is a row in wp_posts, with its useful fields scattered across wp_postmeta as key-value pairs — one row per field, per order. The customer's email, the shipping total, the payment method: all separate rows. Line items live in wp_woocommerce_order_items and wp_woocommerce_order_itemmeta, in the same shape.

Point a generic connector at that and you get an honest copy of the mess: a postmeta table with tens of millions of rows and no way to answer "what did we sell last month" without rebuilding the model yourself. The extraction is the easy half; the modelling is the work.

Then there's the load itself. A full refresh scans the biggest tables you own, and it does it against the same MySQL instance that renders your product pages. It's usually fine, right up until the night it isn't.

Three ways to do it

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.

Managed ETL service

A hosted connector reads your MySQL (or the WooCommerce REST API) and writes to BigQuery on a schedule.

  • Set up in an afternoon, nothing to maintain
  • Handles schema drift and retries for you
  • Priced per row or per active table — WooCommerce's postmeta makes that expensive fast
  • Still reads production on every refresh
  • You get raw tables; the WooCommerce data model is still yours to rebuild

Build the pipeline yourself

A read replica, or Datastream / Debezium reading the MySQL binlog, landing raw tables in BigQuery that you then model with dbt or scheduled SQL.

  • Full control, near-real-time if you use CDC
  • Cheapest at large scale once it's running
  • Needs binlog access, replication privileges and someone to own it
  • Days of setup, then ongoing maintenance when the schema shifts
  • Not realistic on most shared or managed WooCommerce hosting

Clone to PostgreSQL first, then load

BeQuery

BeQuery pulls your MySQL into an isolated, verified PostgreSQL copy. You query it directly — or export from the copy into BigQuery, so the heavy reads never hit your shop.

  • Extraction runs once, against a copy nobody depends on
  • Row counts verified against the source on every sync
  • Ready-made WooCommerce insights, so you may not need the warehouse at all
  • Read-only PostgreSQL that Metabase, Grafana and Looker Studio read natively
  • No one-click push into BigQuery — the load step is yours to schedule
  • Sync is scheduled, not streaming (down to about a minute on higher plans)

The path through a clone, step by step

  1. 1

    Connect your store to BeQuery

    Read-only MySQL credentials, host and port. BeQuery connects, discovers your tables and clones them into an isolated PostgreSQL schema that only your team can reach.

  2. 2

    Let it sync on a schedule

    Each sync rebuilds the copy and verifies it — row counts are checked against the source, so you know the data is complete rather than hoping it is. Production only ever sees a read.

  3. 3

    Query it directly, or load it onward

    Most people stop here: the clone is a real PostgreSQL database with a SQL editor, ready-made insights and BI connections. If you specifically need BigQuery, export the tables you care about from the clone and load them with bq load — the extract now runs against the copy, not your shop.

  4. 4

    Schedule the load

    Run the export-and-load step on your own cron, after the sync completes. Because it reads the clone, it can run as often and as heavily as you like without a single query reaching production.

Do you actually need a warehouse?

Worth asking before you build anything. A warehouse is the right tool for some of these situations and overkill for the rest.

Yes — build it

  • You're joining store data with ad spend, CRM or offline sales from other sources
  • You're already on Google Cloud and your team writes BigQuery SQL daily
  • You're past hundreds of millions of rows, or feeding ML models

Probably not — a clone is enough

  • You have one store and want answers about revenue, products, stock and customers
  • Nobody on the team wants to own a pipeline and a dbt project
  • What you actually need is a weekly report in your inbox and a place to run ad-hoc SQL

Common questions

Can I skip BigQuery entirely?

For a single WooCommerce store, usually yes. A warehouse earns its keep when you're joining several sources or working at a scale a normal database struggles with. If the goal is knowing your revenue, margins, repeat rate and what to restock, a clean PostgreSQL copy of your store answers that today — and BeQuery ships those answers pre-built.

Does BeQuery flatten the postmeta mess?

For the metrics it computes, yes — the built-in WooCommerce insights read order items and meta and give you revenue, AOV, LTV, repeat rate and top products directly. The raw tables are cloned faithfully too, so anything you write yourself in SQL sees exactly the structure WooCommerce uses.

Is BeQuery a BigQuery connector?

No, and we'd rather say so plainly. BeQuery clones your store's MySQL database into an isolated, verified PostgreSQL copy. There is no one-click push into BigQuery. What BeQuery removes is the hard part — pulling data out of a live shop safely and keeping it fresh — after which loading into BigQuery is an ordinary export-and-load step against a copy that nobody depends on.

Why not just point an ETL tool straight at my production database?

You can, and for a small shop it may be fine. The catch is that every full refresh reads your production tables while customers are shopping, and the tables that grow fastest are usually tracking and log tables you don't want in a warehouse anyway. Extracting from a copy means a heavy read can never turn into a slow checkout.

How fresh is the data?

As fresh as your sync schedule — nightly on the lower plans, hourly and faster on the higher ones. For a warehouse used for reporting, nightly is usually what people land on regardless of what the tool supports.

See it on your own store first

Free tier, no credit card, read-only access. Production is never written to — and you can explore the demo store before connecting anything.