MySQL + Querri
Your store or app already writes every order, customer and subscription to MySQL. Ask about them in plain language and get answers that also know your marketing, support and finance data, from a copy Querri keeps in sync away from production.
Read-only from end to end: Querri never changes a row in MySQL. SOC 2 Type II, HIPAA and ISO 27001:2022 certified.
Why MySQL reporting gets hard
Ask anyone who owns the database at an online store or a web app. These are the walls a simple business question runs into.
Analysis queries run on the same database that takes orders. One heavy query at the wrong hour and checkout slows down, so reporting waits for a replica or for midnight.
Status is stored as a number, prices sit in cents, attributes hide in JSON columns and deleted rows only carry a flag. Anyone who doesn't know the code reads the tables wrong.
When an order is refunded or a plan is downgraded, the row is updated in place. Unless someone built an audit table, last month's numbers can't be rebuilt from this month's data.
The campaign is in HubSpot, the ticket in Intercom, the payout in the accounting system. MySQL can't join to any of them, so every cross-system question starts as an export.
Marketing, support and finance all need SQL written for them. Dates add their own trap: DATETIME columns carry no time zone, so "yesterday" depends on who wrote the query.
What you can finally answer
Each is a question ecommerce and product teams put to their app database, why it stalls today, and how Querri answers it.
Why it's hard
Orders, refunds and discount codes sit in separate tables, and the channel a customer came from isn't in MySQL at all.
With Querri
Tell Querri once that revenue means paid orders net of refunds, and the rule lives in Facts & rules. Connect HubSpot for the channel, and the channel-to-revenue playbook shows the rest.
Why it's hard
Every purchase is in the orders table, but cohort retention means window functions and date math that only a developer writes, and it has to be rewritten next month.
With Querri
Ask for repeat purchase by first-order month. Querri saves the work as a project with steps you can open, check and rerun on the next sync.
Why it's hard
The subscriptions table holds each plan as it is today. Upgrades, downgrades and cancellations overwrite the row, so the trend is gone.
With Querri
Define MRR and churn as KPIs and Querri records their history from the day you start. Nightly insights tells you when either one moves away from its usual range.
Why it's hard
The order is in MySQL and the conversation is in the support tool. Linking them by customer email is a spreadsheet job nobody repeats.
With Querri
Connect Intercom next to MySQL, and Querri matches conversations to customers and their orders, saying how it matched them. The ticket drivers playbook goes step by step.
Why it's hard
Signups, events and plan changes are spread across app tables whose meaning lives in the code, and status 3 means nothing to the growth team.
With Querri
Say once what each status code and flag means, and Querri checks columns for odd values before it answers. The signup-to-first-value playbook builds the funnel; data cleansing covers the checks.
Why it's hard
Today a developer runs the query, pastes the result into Excel, fixes the formatting and emails it. Miss a month and nobody notices until close.
With Querri
Build the workbook once. A schedule reruns it on fresh MySQL data and emails a formatted file through reports and automation; Excel tools handles the layout.
Why it's hard
The app database holds every tenant in the same tables. Giving someone a login to it shows them everyone.
With Querri
Set a row filter per person in Workspaces & access and it follows them everywhere. To show customers their own stats inside your app, use Embed.
Why it's hard
Pasting production credentials into an assistant is a security review nobody wants, and the assistant still has to guess what each column means.
With Querri
Add Querri to Claude or ChatGPT as a connector. The assistant answers from your Library, with your rules and each person's access, and never touches the database.
MySQL plus the rest
Marketing knows where a customer came from, support knows what went wrong, accounting knows what was paid. Querri loads them into the Library beside your MySQL tables, and a single question can draw on every one.
MySQL pairs well with
Answers you can stand behind
Ask how many active customers you had in September and you could mean anyone who placed an order that month, or anyone with a live subscription on the last day. Both are reasonable and they don't match. Querri picks one, tells you which, and puts the other count beside it. See how answers work.
Wake up to what changed
Each night Querri compares your KPIs with their own past and goes looking for the corner of the business no one has asked about. Overnight findings are listed in your Inbox before the first coffee, and none of them triggers a change until you approve it.
Custom MySQL dashboards
Say what the dashboard should show, or hand Querri a screenshot of a dashboard to start from. It reads from the same Library as chat, so a chart and an answer never disagree, and you can limit each person to their own rows.
Reports you can stop rebuilding
Paid orders from MySQL tied to the campaign or source that brought each customer in.
Read the playbookHow many new accounts reach first real use, and how long it takes them.
Read the playbookOrder frequency, plan changes and tickets rolled into one score per account.
Read the playbookWhich products and order problems send customers to support again and again.
Read the playbookSubscription revenue, upgrades and cancellations, with history kept from day one.
See KPIsA formatted Excel file for finance, refreshed and emailed on schedule.
See Excel toolsWhat comes over
Querri copies tables from the one MySQL database you choose and keeps the copy current, so questions never run against production. It can only read what the MySQL user you connect with has been granted.
From the database you choose
A full refresh runs on a schedule, daily by default. Incremental syncs pull rows whose cursor column, updated_at unless you choose another, has moved past the last sync, hourly by default.
Tables stream into columnar files instead of loading into memory, so a large orders table doesn't stall the sync. New connections start capped at 100,000 rows; raise or remove the cap under Advanced.
Querri attaches your database read-only and runs nothing but SELECT queries. No insert, update or delete ever reaches your tables.
Your password is stored encrypted and SSL is on by default. The password goes into a secure form; the Connector Agent only learns that it is set.
How to connect MySQL
Tell the Connector Agent "connect our MySQL database," or find MySQL in the Connect catalog.
Allow Querri's IP address on your database firewall. For a private network, add an OpenVPN tunnel instead.
Host, port, database, username and password go into a secure form. A read-only MySQL user is the safest choice.
Querri tests the connection and lists the databases you can see. Bring over all tables, a chosen few, or the results of named SQL queries.
No data moves until you say yes. Choose full or incremental syncs, and the tables land in your Library.
MySQL FAQ
Ask the Connector Agent to connect MySQL, or choose it in the Connect catalog. Allowlist Querri's IP on your database firewall, fill in host, port, database, username and password in the secure form, and run the test. Finally, select the tables you want and approve the load and its schedule.
Querri syncs base tables and views from the one database you choose, either all of them or a list you pick. You can also add named SQL queries, each of which becomes its own source. It can only read what the connected MySQL user has been granted.
A full refresh runs on a schedule you set, daily by default. Incremental syncs can run as often as hourly, pulling rows whose cursor column, updated_at by default, has moved past the last sync. A manual sync is available whenever you need fresher data.
No. Querri only reads your data and never changes your records. It attaches the MySQL database read-only and Querri runs nothing but SELECT queries, so it never inserts, updates or deletes a row.
Querri reads from MySQL when a sync runs, not when someone asks a question. Questions, dashboards and reports all run on Querri's copy. Schedule full refreshes for quiet hours, use incremental syncs for big tables, or point Querri at a read replica.
MySQL grants decide what Querri can sync: it sees only what the connected user is allowed to SELECT, so give that user exactly the tables that belong in Querri. After that, row visibility for each person comes from Querri's sharing and row filters, not from MySQL.
Connect both, and Querri matches HubSpot contacts to customers in your MySQL tables, usually by email. You can then follow a campaign or source through to paid orders. When a match is uncertain, for example because a customer used two addresses, the answer says so.
Connect both, and Querri links support conversations to customers and their orders in MySQL. You can ask which products, order states or plans generate the most tickets, and see repeat contacts per customer, without anyone exporting either side to a spreadsheet.
Connect MySQL for orders and refunds and HubSpot or a sheet for where customers came from. Tell Querri once what revenue means, such as paid orders net of refunds, and ask. Save it as a project and schedule it to arrive every week.
Define MRR and churn as KPIs in Querri. Because the subscriptions table usually stores only each plan's current state, Querri keeps the KPI history itself from the day you start, so you can see month-over-month movement going forward.
Yes. Turn the report into a project once and give it a send date. Querri reruns it on freshly synced MySQL data and emails a formatted Excel workbook, or one version per client or manager, with no query to run by hand.
Yes. Say what it should show, or begin from a screenshot of an existing dashboard. Edits are requests in plain language, charts can combine MySQL tables with other connected systems, and a row filter keeps each viewer to their own data.
Yes. Querri plugs into Claude or ChatGPT as a connector, set up a single time. From then on the assistant answers from your Querri Library, with your definitions and rules and each person's access, and never gets credentials to your database. Its numbers come from the same definitions your dashboards use.
Amazon RDS for MySQL uses the same host-and-port form as any MySQL server, as long as Querri's IP is allowed or a VPN is set up. MariaDB connects through the same MySQL connector. Each connection reads one database, so several databases mean several connections.
Users on caching_sha2_password, the MySQL 8 default authentication plugin, may fail to connect. Querri's error message says so; the fix is to switch that user to mysql_native_password. Also check that Querri's IP is allowed on your firewall.
Each connection covers one database. Incremental syncs need a cursor column that only increases, only add rows and don't catch deletes, so run a full refresh to clear them. A custom query has no incremental mode; every sync runs it from scratch. There's no SSH tunnel and no real-time binlog replication.
Yes, through an OpenVPN tunnel: upload your .ovpn file with the CA certificate, client certificate and client key, all stored encrypted. Querri doesn't offer SSH tunnels, so a database behind a bastion host needs VPN access or an allowlisted IP.
Querri is SOC 2 Type II, HIPAA and ISO 27001:2022 certified, and your data is never used to train a model. Your password is stored encrypted, SSL is on by default, and the Connector Agent never sees the password. Note that the server certificate isn't verified.
Keep exploring
Connect one database, approve the first load, and ask. Querri only reads, so production stays exactly as it is.