There's no official Google connector for MySQL, which is why every answer you find involves a script, an add-on, or a manual export. Here's what each one actually costs you.
Getting the data across once is easy. Run the query, export CSV, import. The problem is the second time, and the twentieth: manual exports drift, someone edits the query, and the definition of "revenue" quietly changes between two versions of the same report.
Automating it means letting Google reach your database. Apps Script's JDBC service can connect to MySQL, but your server has to accept connections from Google's published IP ranges — which for most people means opening a production database to a broad slice of the internet, protected by a password. It works. It's also the single riskiest line in most small-company infrastructure.
And whichever route you pick, the refresh runs against a server that's doing real work. A dashboard that refreshes every fifteen minutes is a query every fifteen minutes, forever, competing with whatever your application is doing.
All three work. They differ in what you expose, what you maintain, and what the refresh costs your production server.
A script bound to the sheet opens a JDBC connection to MySQL and writes query results into a tab on a time trigger.
A third-party Sheets add-on that stores your credentials and refreshes queries on a schedule.
BeQuery maintains an isolated, verified PostgreSQL copy of the MySQL database. You query the copy and export a result that's already the answer.
Read-only MySQL credentials, host and port. BeQuery clones the database into an isolated PostgreSQL copy that only your team can reach — the shop itself is only ever read.
This is the step that decides whether the spreadsheet survives. In the SQL editor, aggregate first: revenue by month, margin by product, customers by cohort. You want the answer, which is hundreds of rows, not the raw orders table, which is hundreds of thousands.
Save the query, then either export CSV or XLSX from the editor for a one-off, or publish the query as a CSV link. XLSX exports are capped at 500,000 rows; CSV will happily hand you more than a spreadsheet can hold, which is another reason to aggregate first.
Drop =IMPORTDATA("…your link…") into a cell. Sheets fetches it on its own — roughly once an hour — so the tab stays current without anyone exporting anything again. Build your charts and pivots on top of that range. The link is a password in URL form: anyone who can see the formula can read the results, and you can revoke it from BeQuery at any time.
Sheets is a superb interface for thinking and a poor one for storage. The line between the two is where this decision lives.
No — the JDBC service supports MySQL, Microsoft SQL Server and Oracle, and PostgreSQL isn't on the list. It's worth knowing before you plan around it: for a PostgreSQL copy, the routes into Google's tools are a CSV link the sheet pulls with IMPORTDATA, a manual export from the SQL editor, or Looker Studio reading it with the native PostgreSQL connector.
It can refresh itself. Publish a saved query as a CSV link, paste =IMPORTDATA("…") into a cell, and Sheets refetches it on its own — about once an hour. Worth being precise about the direction: BeQuery doesn't write into your spreadsheet, the spreadsheet pulls from BeQuery. Nothing is pushed, nothing is stored in Google on our side, and revoking the link stops it immediately.
Treat it as a password. It's fetched anonymously by Google, so the URL itself is the credential — anyone holding it, including anyone who can open your spreadsheet and read the formula, can see that query's results. It's deliberately narrow: one saved query, read-only, row-capped, and revocable. We store only a hash of it, which is why it's shown once when you create it and can't be retrieved afterwards. For anything sensitive shared widely, use Looker Studio on a read-only connection instead.
Google Apps Script can open a JDBC connection to MySQL, so it is technically possible. It means exposing your production database to Google's IP ranges, writing and maintaining the script, and having every refresh query the same server that serves your customers. It's a lot of moving parts to end up with a spreadsheet that occasionally times out.
Google Sheets caps a spreadsheet at 10 million cells across all its tabs. That sounds enormous until you divide by columns: a 20-column export runs out at around 500,000 rows, and performance gets unpleasant well before the hard limit. Aggregated results are never a problem; raw order lines from a busy store are.
Free tier, no credit card, read-only access. Production is never written to — and you can explore the demo store before connecting anything.