Magento gives you clean sales tables and then hides your product catalogue behind EAV. Both facts shape how you should move it into a warehouse — and whether you need to at all.
Magento's sales tables are a pleasure: sales_order and sales_order_item hold real columns with real totals, and base_grand_total means what you'd expect. Revenue analysis is genuinely straightforward once you filter on the right order states.
The catalogue is another story. Magento stores product attributes in EAV — catalog_product_entity holds the skeleton, while names, prices and everything else live in catalog_product_entity_varchar, _decimal, _int and _text, keyed by attribute id. Getting "products with their names and prices" means several joins and a lookup into eav_attribute. Copy the tables raw into BigQuery and that puzzle travels with them.
Magento installs are also large — 300 to 400 tables is normal — and a lot of that is indexing and staging machinery that has no analytical value at all.
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 connector replicates selected MySQL tables into BigQuery.
Binlog CDC or a replica into BigQuery, then dbt models to flatten EAV into something usable.
BeQuery clones Magento's MySQL into an isolated PostgreSQL copy with native Magento insights on top. Query it directly, or export from it into BigQuery.
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.
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.
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.
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.
Worth asking before you build anything. A warehouse is the right tool for some of these situations and overkill for the rest.
In practice, state in ('complete','processing') on sales_order, summed on base_grand_total — that excludes canceled, closed and pending_payment orders that would otherwise inflate every figure. It's the definition BeQuery's Magento insights use.
Yes. Magento support was validated end-to-end on a real Magento 2 store — 387 tables cloned and verified, with every insight checked against the source rather than assumed.
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.
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.
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.
Free tier, no credit card, read-only access. Production is never written to — and you can explore the demo store before connecting anything.