Managed MySQL speaks MySQL
Connect MySQL HeatWave to Excel, Sheets and AI
Oracle MySQL HeatWave on OCI or AWS. One product, two very different network shapes — the card walks you through which one you have.
One connection, every surface
Where your MySQL HeatWave data can go
Connect MySQL HeatWave once and the same read-only connection feeds all of these — no second setup, no second copy of the data. 9 of 11 have a step-by-step guide.
MySQL HeatWave to Excel
Microsoft Excel · Excel add-in
Pull live MySQL HeatWave results straight into a worksheet and refresh them on demand — desktop Excel, Excel Online, Microsoft 365.
Read the MySQL guideMySQL HeatWave to Google Sheets
Sheets add-on
Run a saved MySQL HeatWave query from the sidebar and drop the rows into the sheet. Shared collaborators can refresh it themselves.
Read the MySQL guideMySQL HeatWave MCP server
Claude, Cursor and MCP clients
Give an AI assistant read-only access to MySQL HeatWave with the schema it needs to write correct SQL — no credentials in the chat.
Read the MySQL guideMySQL HeatWave REST API
HTTP endpoint
Publish a MySQL HeatWave query as an authenticated JSON endpoint any application can call, with an OpenAPI 3.1 spec and ready-made Postman, Insomnia and Hoppscotch collections. No database port is opened.
Read the MySQL guideMySQL HeatWave to Airtable
Automation platform
Sync MySQL HeatWave rows into an Airtable base on a schedule, or fetch them inside an Airtable automation script.
Read the MySQL guideMySQL HeatWave to Baserow
Automation platform
Feed a Baserow table from MySQL HeatWave over the REST endpoint — self-hosted or Baserow cloud.
Read the MySQL guideMySQL HeatWave to SeaTable
Automation platform
Keep a SeaTable base current with MySQL HeatWave data without exporting a file or exposing the database.
Read the MySQL guideMySQL HeatWave to Smartsheet
Automation platform
Push MySQL HeatWave results into a Smartsheet grid so plans and reports read from the source system, not last week's export.
Read the MySQL guideMySQL HeatWave to Anvil
Anvil Works · App platform
Back an Anvil Python app with MySQL HeatWave through the REST endpoint instead of embedding database credentials in the app.
Read the MySQL guideMySQL HeatWave to Power BI
Power Query M
Paste the generated Power Query M into the Power BI Advanced Editor and the report reads live MySQL HeatWave results over HTTPS — no ODBC driver, no database port opened.
How Power BI works no MySQL HeatWave walkthrough written yetMySQL HeatWave alerts and reports
Slack · Discord · Email · Webhook
Put a MySQL HeatWave query on a schedule and have the rows delivered to Slack, Discord, email or a signed webhook — or hold the message until a row count, threshold or percentage change crosses the line you set.
How alerts and reports work no MySQL HeatWave walkthrough written yetHow it works
5 steps, no inbound firewall change
Work out which shape you have. HeatWave on OCI is private to your VCN; HeatWave on AWS exposes a public endpoint.
Put the Network Agent where it can reach the endpoint. For OCI that means a Compute instance in the same VCN, talking to the DB system's private endpoint. For AWS the agent can sit wherever you like.
Enter the endpoint. It is a private IP on OCI and an FQDN on AWS, and the port is 3306 in both cases.
Fill in the database, username and password. There is no default username here — HeatWave systems are created with an admin user you chose, not a conventional one.
Leave Use SSL on and save. Microsoft Excel, Google Sheets, Power BI, MCP and REST all read through that one connection, or join it to your other sources in a single read-only statement.
Feature deep-dive
What MySQL HeatWave gives you
OCI is private, AWS is public, and it changes where the agent goes
HeatWave is sold as one product but deployed in two shapes, and the difference decides your install location rather than your connection settings.
- On OCI, a HeatWave DB system lives inside your VCN and is not reachable from the internet. Put the agent on a Compute instance in that same VCN and point it at the private endpoint.
- On AWS, HeatWave exposes a public TLS endpoint. The agent can run anywhere that can reach it, including on your own hardware.
- Either way the agent only makes outbound connections. There is no inbound rule to add, no ingress to open on the VCN and no VPN between your network and ours.
- The connection settings themselves do not change between the two. Same port, same fields, same driver — only the endpoint and the sensible agent location differ.
TLS is the checkbox, and it is on by default
Worth being precise about, because HeatWave's two deployment shapes have genuinely different exposure.
- Use SSL is on by default, and while it is on the connection is encrypted — the agent asks MySQL for a required TLS session.
- Turn it off and the agent will attempt an unencrypted connection. Nothing here overrides that based on the endpoint, so the checkbox is the whole mechanism.
- That matters most on AWS, where the endpoint is public. Over the public internet, leaving TLS on is not optional in any practical sense.
- Encryption is not certificate verification. The agent requires TLS but does not validate the server's certificate chain, so treat it as protection against eavesdropping rather than proof of what you reached.
Underneath it is MySQL, which is the point
HeatWave's analytics engine is Oracle's business. What reaches Query Streams is a MySQL connection.
- The agent connects with a standard MySQL driver and runs ordinary read-only SQL. Nothing about the query path is HeatWave-specific.
- MySQL has no separate schema layer, so the database is the qualifier. That is what a cross-source reference carries.
- Cross-database queries on one HeatWave connection work the way they do on any MySQL server, so a single connection can reach more than one database.
- A read-only user is worth creating. Query Streams will not write, but the safest way to guarantee that is at the database rather than in the tool.
-- Ordinary MySQL, read-only, over TLS
SELECT c.name,
COUNT(o.id) AS orders,
SUM(o.amount) AS revenue
FROM customers AS c
JOIN orders AS o ON o.customer_id = c.id
WHERE o.placed_at >= NOW() - INTERVAL 30 DAY
GROUP BY c.name
ORDER BY revenue DESC;
Shared by every database connector
True of every database connector
- Outbound only — the agent opens one encrypted connection out to Query Streams. No inbound port to forward, no VPN, no IP allowlist, nothing about your database exposed to the internet.
- Credentials stay put — the database username and password live on the machine you installed the agent on. Query Streams never receives them and cannot reach your database on its own.
- Read-only, enforced — one statement at a time, SELECT and friends only. A write is rejected on your own machine before it is ever sent to the server, rather than relying on a permission somebody remembered to set.
- Deploy as many agents as you like — one per site, region or cloud. Every data source they can see arrives in a single dropdown, so nobody has to know which agent hosts what.
What you get once a query is saved
- Share the capability, not the SQL — a colleague or an outside partner can run your query and change its filters without ever seeing the statement behind it.
- Filters from either direction — declare them yourself as @variables, or let the connector spot the literal values already sitting in your WHERE clause and offer those as dropdowns.
- Read it from anywhere — Microsoft Excel, Google Sheets, Power BI, the REST API, AI assistants over MCP, the Query Builder and Nova all read the same saved query.
- Run several at once — five saved queries into five worksheet tabs, streamed concurrently, however large the results.
- Join it to anything else you have connected — another database, a business API, or a folder of files, in one read-only statement.
Cross-source SQL
Join MySQL HeatWave to the rest of your data
One statement can span MySQL HeatWave and your other connections at once. Each source runs only the part it can, streams the result back, and the join happens centrally — the sources never talk to each other and nothing is copied anywhere.
3 connections · 3 agents
One statement
-- nothing copied, nothing merged, nothing scheduled
SELECT c.region, COUNT(*) AS orders, SUM(i.amount_due) AS invoiced
FROM heatwave_ops.shopdb.orders1 f
JOIN pg_crm.public.customers2 c ON c.id = f.customer_id
JOIN billing.stripe.invoices3 i ON i.customer = c.stripe_id
GROUP BY c.region
ORDER BY invoiced DESC;
The three parts are connection, schema and table — and the connection name is whatever you called it. Illustrative columns; your tables will be your tables. Read-only applies to every piece: SELECT, WITH and EXPLAIN only, with a ceiling on how much any one source may hand over for a single query. How federated queries work
Connection details
What MySQL HeatWave needs
- Endpoint
- A private IP on OCI, an FQDN on AWS
- Port
- 3306
- Driver
- MySqlConnector, carried by the agent — nothing to install at the Oracle end
- Agent placement
- On OCI, a Compute instance in the same VCN as the DB system. On AWS, anywhere that can reach the public endpoint
- TLS
- Controlled by the Use SSL checkbox, which defaults on. Encrypted while it is on; the certificate chain is not verified
- Username
- No default. HeatWave systems are created with an admin user you named
- Pooling
- None exposed, and the agent applies no pooler adaptations here
- Saved as
- MySQL. HeatWave speaks the MySQL wire protocol, so everything downstream is ordinary MySQL
- Default schema
- The database itself. MySQL has no separate schema layer, so a federated reference carries the database name
The OCI and AWS split is the only thing on this card that will genuinely catch someone out, which is why it leads. On AWS, HeatWave behaves like any other managed MySQL with a public endpoint and there is nothing to think about. On OCI it is private to your VCN by design, and no amount of correct credentials will help an agent sitting outside it. Getting the agent onto a Compute instance in the right VCN is the whole job, and it is an infrastructure decision rather than a connection setting.
There is no paste box on this card, and that is deliberate rather than an omission. OCI does not hand you a ready-made connection URI the way Heroku or Railway do — you assemble the endpoint from the DB system's details — so a paste field would be a box with nothing to put in it. Typing five fields is the honest shape of this one.
For a cross-source query MySQL qualifies by database rather than by schema, so a connection you called heatwave_ops reaches a table as heatwave_ops.shopdb.orders — the database sits where a schema would on the Postgres cards. It joins to a folder of CSVs, an on-premises system of record or a billing API in one read-only statement — with nothing copied and nothing scheduled.
Vendor documentation: www.oracle.com
FAQ
Questions about MySQL HeatWave
Which tools can read MySQL HeatWave data through Query Streams?
All of them, from one connection: Excel, Google Sheets, MCP, REST API, Airtable, Baserow, SeaTable, Smartsheet, Anvil, Power BI, scheduled alerts and reports. Connect the database once and every surface reads the same read-only connection — there is no per-tool setup and no second copy of the data.
Do I have to open a firewall port to my MySQL HeatWave database?
No. The Query Streams Network Agent runs inside your network and opens a single outbound encrypted connection. Nothing listens for inbound traffic, no VPN is required, and the database keeps its existing firewall rules.
Can Query Streams change data in MySQL HeatWave?
No. The agent enforces read-only at the point of execution — one statement at a time, SELECT and friends only. Credentials stay on the agent and are never sent to Query Streams.
What does Query Streams need to connect to MySQL HeatWave?
A reachable host, a role and its password — the agent carries the driver, so nothing is installed on the database. Endpoint: A private IP on OCI, an FQDN on AWS. Port: 3306. Driver: MySqlConnector, carried by the agent — nothing to install at the Oracle end. Agent placement: On OCI, a Compute instance in the same VCN as the DB system. On AWS, anywhere that can reach the public endpoint.
Can I join MySQL HeatWave to another database in the same query?
Yes — that is a federated query. One statement can reference MySQL HeatWave and your other connections at once, written as connection.schema.table. Each source runs only the part it can and streams the result back; the join happens centrally, so the sources never connect to each other and nothing is copied or scheduled. Read-only applies to every piece — SELECT, WITH and EXPLAIN only — and there is a ceiling on how much any one source may hand over for a single query. Federated queries are a plan feature; the federated queries page carries the current source and size limits.
Is connecting MySQL HeatWave different from connecting MySQL?
Only the connection string. MySQL HeatWave speaks the MySQL wire protocol, so filters, scheduling, sharing, the Excel and Google Sheets add-ons and the MCP server all behave identically. The MySQL HeatWave card pre-fills the host, port and SSL settings that provider expects.
Is there a MySQL HeatWave to Excel guide?
Yes — it is the MySQL guide, and it is correct for MySQL HeatWave as written. MySQL HeatWave speaks the MySQL wire protocol, so MySQL HeatWave to Excel, MySQL HeatWave to Google Sheets and every other destination follow the same steps. The only MySQL HeatWave-specific part is the connection string, and the MySQL HeatWave card fills that in for you.
Put MySQL HeatWave where the work happens
Install the agent, point it at your database, and pick a destination.
Read-only Outbound only Credentials stay on the agent

