PrestaShop's schema is far friendlier than most — real orders and order_detail tables you can actually read. The problem is everything around it: hundreds of tables, multi-shop and multi-language splits, and tracking tables that dwarf your real data.
The good news: PrestaShop models orders properly. ps_orders, ps_order_detail, ps_customer and ps_product are close to what you'd design yourself, and useful SQL against them is short. Compared with a WordPress store, you start ahead.
The bad news is volume in the wrong places. A typical PrestaShop install carries several hundred tables, and the largest ones are almost never your business data — ps_connections, ps_connections_source, ps_guest and ps_pagenotfound are visitor-tracking tables that grow forever. On one production store we sync, those four alone account for around 97% of all rows. Copy the database naively and you pay to move, store and refresh tens of millions of rows nobody will ever query.
Then multi-shop and multi-language multiply your product and category tables into _shop and _lang variants, so a naive load gives you several rows per product and revenue that looks inflated until you work out which join was wrong.
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 your MySQL tables into BigQuery on a schedule.
Read replica or binlog CDC into BigQuery, modelled with dbt or scheduled SQL.
BeQuery clones the MySQL database into an isolated PostgreSQL copy, with an exclusion list so the tracking tables never travel. 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.
For almost every analysis: ps_orders, ps_order_detail, ps_order_state_lang, ps_customer, ps_product, ps_product_lang, ps_product_attribute, ps_stock_available, ps_category_lang and ps_cart if you care about abandonment. Everything beginning with ps_connections, plus ps_guest, ps_pagenotfound and ps_report404, is visitor tracking you can almost always leave behind.
A sync is a sequence of reads with a read-only user, and on the plans with scheduling it runs at night. For scale: a production store of ours with 548 tables and over 120 million rows completes a full verified sync in about 50 minutes, with no measurable impact on the storefront.
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.