What we're shipping

When a link needed you to sign in first, you landed on the dashboard afterwards and had to find your way back. Signing in, creating an account and continuing with Google now all return you to the page that asked, and the same holds if you switch between the sign-in and sign-up tabs on the way.

A new workspace now opens with a demo store already loaded — 1,400 orders, working Insights, segments and the SQL editor — so you see what BeQuery does before connecting anything. Connect your own database and the demo is removed by itself; remove it earlier and it stays gone. Until you connect, a few short emails explain how the read-only connection works and offer help, and every one has an unsubscribe link.

On the Starter plan, which includes one database, the demo store was counted as that database: try the demo, then connect your own shop, and you were asked to upgrade. The demo no longer counts against your plan, and the getting-started checklist keeps "Connect a database" open until a real one is connected.

Ask a question in plain language and we show the AI a few real values from each column, so it writes a query that fits your data. It was reading those examples as the complete list: asked for the orders of a product whose reference did not appear among them, it answered that the product was not in your database — when the product was there all along, further down the table. The examples are now labelled as the handful of rows they are, and a value you name is never a reason to refuse. The same pass taught it that dates in a clone are text, so it filters a day by comparing text instead of a conversion that can fail on the empty dates MySQL allows.

A query that opened with a `-- note` was refused as "not a SELECT", one that ended with a comment failed with a syntax error, and a semicolon inside a comment or a string counted as a second statement — because the guard read the raw text rather than the SQL the database sees. Both the SQL guard and the CSV export now read past comments and literals the way the database does. The same pass tightened the guard in two places a second review found: a comment ending in a bare carriage return, and a query closing more brackets than it opened.

The cost of a query on the Cloud plan depends on how many rows you had already read this month, so two queries finishing at the same moment could each be priced as if the other had not happened — and both round up to the next cent. Recording usage now happens in one serialized database step per team: the total is read, the delta priced and the counter updated with nothing in between, so the running total equals the exact rate to the cent.

Teams with more than one database could not export a CSV or Excel file from any but the first: the request was refused as an invalid schema before it reached the database. The check now knows the shape a second database's schema has. Live storage on the billing page also now counts every database, not just the first.

An independent, adversarial review of the platform (two rounds, a different AI model attacking the code) found that the per-client access an agency can grant (v0.9) was enforced by the application but not yet by every layer under it. Row-level security now honours the same grants on reads and writes alike, so a client can see and touch only the databases, saved queries, insight cards, reports, alerts, feeds and sync history they were given, wherever they ask from. Scheduled reports, alerts and Google Sheets feeds are now judged against their creator's current grants every time they run — revoke a client's access and what they set up stops. The SQL guard learned that a quoted or comment-split schema name is still a schema name, and the streaming CSV export applies the same cross-schema rule as everything else. No customer was affected: no scoped members exist yet, and the other paths were only reachable by signed-in users on their own team.

On the Cloud plan, two queries finishing at the same moment could each add their cost to the same starting figure, so one charge went missing from the running total (in your favour, but wrong). The counter is now incremented in a single database step.

A saved query with a long name or description spilled its text across the page instead of shortening it, and squeezed the author and date underneath onto two ragged lines. Text now stops cleanly at the card's edge, with the full description on hover, and the footer stays on one line however the query is named and described.

Profit (30 days) needs a supplier or wholesale cost on your products, and PrestaShop leaves those fields optional. On a shop that has not filled them in, the card was showing €0 — a confident, wrong figure rather than an absent one. It now says what is missing and what to fill in. The same fault was in every big-number card: an empty result rendered as 0, and now renders as a dash.

Insights used to count an order when PrestaShop's own `valid` flag said so. That flag is a cached copy written only when PrestaShop itself changes an order's status, so orders created by an import, a migration or an ERP stay marked invalid however paid and delivered they are — and were being left out. Figures now read the order's actual status instead, which can only find orders the old test missed. Repeat customer rate also stops counting free and zero-value orders: a sample is not a purchase, and counting one turned a one-time buyer into a returning customer. On a shop of 32,000 orders that moved the repeat rate from 20.1% to 18.3%, which is the truer number.

Pointing BeQuery at an address like 127.0.0.1 or 192.168.1.50 used to fail with whatever the connection attempt happened to say. It now explains the actual problem — those addresses mean something only inside your own network, and BeQuery connects from its servers — and points at the SSH tunnel option, which is what that situation calls for. BeQuery will no longer open connections to private or internal addresses at all, whichever screen the request comes from.

Removing a database used to remove it from BeQuery while leaving the cloned tables sitting in PostgreSQL — unreachable and uncounted, but still there. Deleting a database, deleting a team, or removing the demo workspace now drops the copied data for good. A safety check refuses to drop anything another database is still using, so this can only ever remove data nothing points at.

/for/agencies does the arithmetic you're already doing on the back of an envelope: ten client stores on Business work out at €14.90 each per month, twenty-five on Scale at €13.96, with client logins on top for free. It's equally clear about what the package isn't — there's no white-labelling, no per-client billing, and limits are shared across the whole account rather than per store.

Someone invited to a single database now gets a product that matches what they're allowed to do: no prompts to connect a database they can't connect, no setup checklist meant for account owners, and a plain message while they're waiting for a store to be shared with them. Plan limits and the upgrade prompt are now shown only to members who can manage billing — on the dashboard as they already were in Settings — so a client never sees the account's plan or how many databases are in it.

Every database now has a Client access section: invite someone by email and they get a login that reaches that database and nothing else — not the other databases in your account, and not the connection settings of the one they can see. They can run their own queries and refresh their own data. The Team page gained a Scope column so you can tell at a glance who is restricted to which store, and revoking access from the database page takes effect immediately.

Members restricted to a single database no longer count against your plan's team member limit. The limit is there to price people working inside your account, and giving a client a window onto the store you already sync for them isn't that — so an agency never has to choose between hiring someone and onboarding a client. Ordinary team members count exactly as before.

A team's second (and third, and fourth) database was being refused by the safety check that validates database names, because that check predates the multi-database feature and never learned the newer naming. Querying one came back with an error about an invalid name, its table sizes were missing from the Tables tab, and its storage went uncounted in the nightly usage snapshot. Teams with a single database were never affected.

The rule about which databases a person can read is now applied inside PostgreSQL, not only in the app. Anyone connecting straight to the data API with their own credentials is held to exactly the same limits as someone using BeQuery in the browser: for a member restricted to specific databases, asking for one they weren't given is refused outright. Nothing changes for an ordinary team, where every member reaches every database.

Every screen and endpoint that turns a request into "which database do I read" now asks who is asking, instead of asking only which team they belong to. Nothing changes for existing teams — every member still reaches every database in their team. It is the groundwork for the agency package, where a client gets access to their own store and nothing else, and where asking for a database you weren't given has to come back empty rather than quietly falling back to the team's first one.

The Looker Studio page now answers the question people actually arrive with: there is no export step, because Looker Studio reads PostgreSQL natively. It compares the three real routes, says plainly when connecting directly is the right call and you don't need us, and explains the one that matters — that a shared report means Google's servers querying whichever database you named.

Coming back from Shopify always dropped you on the new-database screen, even when you had started from a store you already had — so saving there created a second copy of the same store. You now return to the store you were editing.

The first sync against a real store failed on its last table: we asked Shopify for read_discounts, but the price rules we read are gated on read_price_rules, so authorization succeeded and then the sync stopped with a permissions error. We now request the right one. Re-authorizing also does what the screen always said it did — until now a store that re-approved permissions kept using its old credential, so nothing actually changed.

Shopify stopped letting merchants create custom apps from their admin on 1 January 2026, which quietly broke the instructions we shipped yesterday: they sent you to a menu that no longer exists. Connecting a store is now one click — you approve four read-only permissions on Shopify and come straight back, with no token to copy. Stores that still have a custom app from before the cutoff can keep pasting their token; that path is still there, just tucked away. We also found our connector was pinned to an API version Shopify retired last October, so it wouldn't have worked even with a valid token.

Shopify is now a source you can connect from the app, not just read guides about. Add a store with its .myshopify.com address and a read-only Admin API token, and BeQuery clones orders, line items, refunds, fulfillments, products, variants, customers and price rules into your own Postgres — eight tables, each keeping the full API object in a raw JSON column. Every sync is a complete refresh, so there is no partial state to reconcile. It's marked beta because it hasn't yet been run against a real store's full order history; if you try it, tell us what breaks.

Three guides for getting Shopify data into BigQuery, Google Sheets and Looker Studio. Shopify is API-only, so BeQuery can't clone it the way it clones a MySQL store — the connector is still in development, and the guides say so plainly while explaining the routes that do work today.

The guides now cover Magento 2 for every destination, not just BigQuery. Both new pages take the EAV catalogue seriously — why product names don't come through in a raw export, and how to write the join once instead of in every chart.

Publish any saved query as a CSV link, paste =IMPORTDATA("…") into a cell, and Sheets refetches it about once an hour — no more re-exporting to update a tab. Find it on the Saved Queries page. The link is a password: it's shown once, it only ever exposes that one query, it's row-capped and read-only, and you can revoke it whenever you like.

Six more guides covering the two places store data actually ends up: Google Sheets and Looker Studio, for WooCommerce, PrestaShop and plain MySQL. The Looker Studio ones are worth a look even if you're happy today — its PostgreSQL connector reads your clone directly, so a shared dashboard never has to query your live shop.

A new /guides section covering WooCommerce, PrestaShop, Magento and plain MySQL into BigQuery. Each one compares the real options side by side — managed ETL, a pipeline you build yourself, or a clone you load from — including where BeQuery isn't the answer and when you don't need a warehouse at all.

A legacy helper from the early days of the clone pipeline could run administrative statements on our database. Nothing in the product had called it for months, so we removed it rather than leave it in place. No behaviour changes for you — this is one less way anything could ever go wrong.

The SQL editor now runs every query strictly inside your own cloned data — a query can no longer reference any other schema or another workspace's tables, whether named directly or not. This closes a gap in the query engine's access checks; your data was always private to your workspace and remains so.

A brand-new workspace now leads with the demo store — a full workspace with 1,400 orders, working dashboards and a live SQL editor, in about ten seconds and with no credentials. Until something is connected, the dashboard no longer offers "New Query" as its main action: it was the one button that couldn't work yet.

When a query hits a table that isn't in your clone, the hint now names the closest matches from your own cloned tables — so a query written against orders finds ps_orders, and a typo is caught immediately. If nothing has been cloned yet, it says so instead of blaming the table name. Every editor hint is now in English, matching the rest of the product.

Opening the editor before connecting anything used to end in a cryptic "relation does not exist" on your first query. Now it shows what to do next — connect a MySQL database, or spin up the sample store in one click. If a database is connected but has never been cloned, a banner points you at the first sync rather than letting every table name fail.

Signing up or signing in with Google now lands on the dashboard with the same session handling and product analytics as email sign-in. No change to what data we collect — this fixes a blind spot where Google sign-ups weren't measured, so we can keep improving onboarding where it actually matters.

Sign in, create account, reset and update-password buttons now use the same brand green as every other call-to-action on the site — they were rendering in a muted default color.

Sign in, sign up and password reset now share a split-screen layout — your form on the left, real production numbers on the right (108M+ rows synced, ~1 min freshness, zero production load). The sign-up page also links to the Terms and Privacy Policy, which was missing before.

The Product and Solutions menus now show what each item actually does, not just its name — plus new /features and /solutions overview pages tying everything together. The nav button is "Start free" everywhere now, including mobile.

The SQL editor finally gets its own feature page — Monaco, schema explorer, AI query generation, MySQL→PostgreSQL translation, and why none of it can ever touch your live store.

The nav button now says "Start free" everywhere instead of mixing in "Get Started". The footer moved Security next to Privacy/Terms where it belongs. The Security page now shows the same production numbers as the homepage (108M+ rows, EU-hosted, integrity-verified).

Clarified how it works — the sync step now says what it actually does (verified, integrity-checked, near real-time on higher plans), and the final step leads with dashboards, reports, alerts and the AI digest, not just the SQL editor. The closing CTA now offers "Talk to sales" alongside the free trial.

Owner, Admin, Developer, Editor and Viewer badges are now each a distinct color, matching the role legend added earlier today — recognize who can do what at a glance.

The Databases page is now a single stacked list instead of a two-column grid, with a "Connect another database" tile at the end so adding one more is always one click away.

Insight cards now pack into a masonry layout instead of leaving gaps under shorter cards, and table-style cards cap at 5 rows so every card reads at a similar size.

Success, warning and error toasts now have a colored left accent matching what they mean, and the command palette (⌘K) has a "Back to site" shortcut.

A new Top products · 30d panel sits next to Needs attention — your four best sellers by revenue, no click into Insights required (though it's one click away if you want more).

The dashboard now greets you by team name and time of day, and the "Data verified" bar shows which platform your clone is detected as (PrestaShop, WooCommerce, Magento).

For stores with a detected PrestaShop, WooCommerce or Magento clone, the dashboard now leads with real revenue, orders and average order value — each with a genuine delta vs the previous 30 days, the same numbers already trusted on the Insights page.

Clone Logs now shows 4 quick stats above the run history — runs shown, average duration, rows in the last successful sync, and success rate.

A quick legend on the Team page now explains what Owner, Admin, Developer, Editor and Viewer can each do — no more guessing before you invite someone.

A new Export button on the Segments page downloads a CSV of every RFM segment — customers, share of base, revenue and average recency/frequency/monetary — alongside the existing per-segment customer export.

The Databases page now shows tables, total rows, sync frequency and last run at a glance on each card — no more clicking in just to see how big a clone is. Added a direct "Sync logs" link per database, too.

Scheduled reports and business alerts now sit next to each other on wider screens instead of stacking, so you can scan both lists at a glance.

A "Query Editor" shortcut in the Tables header, and a "Query this table" button when browsing a table's data — jumps straight to the SQL editor with a SELECT already filled in.

Costs & Profit now has an Export button for the full margin table, and a clearer banner when products are still missing a unit cost — so you know exactly what's excluded from the totals above.

A small reminder next to the editor toolbar: every query you run here executes on your isolated PostgreSQL clone, never on your live store.

The dashboard's revenue chart now has a Weekly/Monthly toggle — 12 months of history at a glance, for PrestaShop, WooCommerce and Magento stores. Same insight cards you already trust, just a longer lens.

Recent alert triggers and scheduled report sends now surface directly on the dashboard, so you don't have to check Automations to know what fired. The revenue chart now sits next to plan usage and needs-attention in a tidier sidebar, and Quick Actions / Recent Queries got an even, full-width layout.

If a database's syncs fail three times in a row (or the data-integrity check keeps failing), we now email your team directly — not just our operators. Your dashboards keep serving the last good sync in the meantime, and the email tells you exactly what's happening and how to trigger a fresh sync yourself.

Built-in insight cards are now cached: your clone's data only changes when a sync lands, so each card recomputes once after a sync and every later page view is served instantly from cache. Big stores feel the difference most — no more re-running heavy queries on every visit.

Include-all connections can now carve out tables that should never be cloned — one name per line, with prefix wildcards like ps_connections*. Perfect for heavy tracking and log tables that can be over 90% of your nightly sync volume without powering a single insight: exclude them and syncs get dramatically lighter. It's your call, and it's reversible — remove an entry and the tables are back on the next sync.

We ran the full BeQuery pipeline against a real Magento 2.4 store: secure SSH-tunnel connection, verified clone of 387 tables, and every Magento insight — revenue, top products, trends, customer lifetime value, repeat rate, profit by product and RFM segments — validated on live data. If you run Magento, BeQuery is ready for you today.

The schema explorer can now peek inside any table: expand it and load a few real rows to see example values next to every column — no more guessing what a column contains before you query it. The AI query generator uses the same sampled values, so it writes queries grounded in your actual data formats, not just column names.

The sync now mirrors your source database indexes onto the clone, so multi-table queries (orders joined with details, discounts, loyalty, returns) run in a fraction of a second instead of minutes. Big exports that used to crawl now finish fast.

Insights is now organizable: reorder, pin, hide and group cards into sections, and add your own cards from any saved query. Built-in insights stay included; custom cards run on a refresh interval you choose and, on the Cloud plan, are metered only when they actually run (not each time you open the page).

Every sync now does a clean full copy of your selected tables — the most reliable and predictable option. We removed the polling-based incremental mode, which could be slower and heavier than a full copy on stores whose tables lack a change-timestamp. True low-latency incremental is coming as a dedicated option for stores that enable database replication.

The site now wears the same green as the integrity badge in the product: clearer calls to action, a pricing page with an obvious recommendation, and the production proof point finally shows the story behind the numbers — three generations of the sync engine, from 2h50m to ~28 minutes.

Real-time connections (Scale and Enterprise) now sync about every minute instead of every 5 minutes. Real-time syncs also run in their own fast lane, so a large nightly re-clone can never delay them.

Data syncs now run on dedicated always-on infrastructure instead of time-limited serverless functions. Large syncs complete in a single pass — no more splitting a big clone into dozens of resumed chunks — which makes them faster and more predictable.

Very large tables that resume across multiple sync windows could re-copy a small overlap of rows and get stuck cleaning up after themselves. Resumed copies now realign to the exact checkpoint before continuing, and the cleanup pass respects the sync's time budget — long syncs keep moving instead of spinning.

bequery.pro grew from a one-pager into a structured site: dedicated pages for every feature, PrestaShop and WooCommerce solution pages with the platform's own templates linked, and a concrete security page. Easier to explore, easier to share.

BeQuery now detects your platform (PrestaShop or WooCommerce) and builds answer cards automatically: revenue and orders vs the previous period, top products, products to restock before they run out, declining products and top customers. Connect, sync, and the answers are just there.

Any saved query can now land in your inbox on a schedule — daily or weekly, at the hour you choose, to the people you choose. The Monday numbers your team asks for, delivered before anyone asks.

Watch any metric and get an email when it crosses a threshold: orders today below 10, stock of a bestseller under 20, weekly revenue dropping. Checked every hour against your synced data, with a cooldown so it never spams you.

Every Monday morning, an AI-written summary of your store's week: what grew, what dropped, what needs restocking — in plain language with real numbers. Available on Business plans and above.

Your dashboard now shows the integrity verification we run after every sync: data verified, how many rows across how many tables, and how fresh it is. You shouldn't have to trust us on faith — the checks are visible.

The table copy now pages by primary-key ranges instead of offsets, making it immune to rows changing mid-copy on a live store and dramatically faster: a 107M-row production clone dropped from ~2h50m to ~65 minutes.

If a scheduled sync tick is ever dropped by the platform, BeQuery now notices within the hour and runs it anyway. A missed nightly sync no longer means a day-old clone.

A processing lease now guarantees only one sync worker touches a run at a time, and the engine detects and automatically repairs duplicate rows if anything ever slips through — with an alert to our operators. Defense in depth for your data.

After every sync, BeQuery verifies the clone against what was recorded as synced — catching silent data issues that a green checkmark would hide. Our operators get a daily health digest, so problems are investigated before you notice them.

One click turns any query result into a bar, line or pie chart — auto-detected from your columns. No export, no spreadsheet.

Scale and Enterprise plans can now sync every 5 minutes, keeping the clone close enough to live for operational dashboards.

Ask-AI now validates the SQL it generates against your real schema before returning it, and repairs it automatically when it doesn't run. Fewer copy-paste-fail loops.

Plan limits now apply to your total cloned rows across all tables instead of penalising any single large table — fairer for real stores where one orders table dominates.