MySQL HeatWave logo

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.

1connection
0inbound ports
read-onlyenforced

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.

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 guide
Guide

MySQL 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 guide
Guide

MySQL 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 guide
Guide

MySQL 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 guide
Guide

MySQL 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 guide
Guide

MySQL HeatWave to Baserow

Automation platform

Feed a Baserow table from MySQL HeatWave over the REST endpoint — self-hosted or Baserow cloud.

Read the MySQL guide
Guide

MySQL 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 guide
Guide

MySQL 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 guide
Guide

MySQL 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 guide
Supported

MySQL 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 yet
Supported

MySQL 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 yet

How it works

5 steps, no inbound firewall change

01

Work out which shape you have. HeatWave on OCI is private to your VCN; HeatWave on AWS exposes a public endpoint.

02

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.

03

Enter the endpoint. It is a private IP on OCI and an FQDN on AWS, and the port is 3306 in both cases.

04

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.

05

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

MySQL HeatWave Managed MySQL
PostgreSQL Relational engine
Stripe Payments & billing

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