Managed · PG + MySQL speaks PostgreSQL / MySQL
Connect OVHcloud Managed Databases to Excel, Sheets and AI
OVHcloud Managed Databases — PostgreSQL or MySQL. Aiven runs underneath, which explains the defaults the moment you see them.
One connection, every surface
Where your OVHcloud data can go
Connect OVHcloud 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.
OVHcloud to Excel
Microsoft Excel · Excel add-in
Pull live OVHcloud results straight into a worksheet and refresh them on demand — desktop Excel, Excel Online, Microsoft 365.
Read the PostgreSQL guideOVHcloud to Google Sheets
Sheets add-on
Run a saved OVHcloud query from the sidebar and drop the rows into the sheet. Shared collaborators can refresh it themselves.
Read the PostgreSQL guideOVHcloud MCP server
Claude, Cursor and MCP clients
Give an AI assistant read-only access to OVHcloud with the schema it needs to write correct SQL — no credentials in the chat.
Read the PostgreSQL guideOVHcloud REST API
HTTP endpoint
Publish a OVHcloud 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 PostgreSQL guideOVHcloud to Airtable
Automation platform
Sync OVHcloud rows into an Airtable base on a schedule, or fetch them inside an Airtable automation script.
Read the PostgreSQL guideOVHcloud to Baserow
Automation platform
Feed a Baserow table from OVHcloud over the REST endpoint — self-hosted or Baserow cloud.
Read the PostgreSQL guideOVHcloud to SeaTable
Automation platform
Keep a SeaTable base current with OVHcloud data without exporting a file or exposing the database.
Read the PostgreSQL guideOVHcloud to Smartsheet
Automation platform
Push OVHcloud results into a Smartsheet grid so plans and reports read from the source system, not last week's export.
Read the PostgreSQL guideOVHcloud to Anvil
Anvil Works · App platform
Back an Anvil Python app with OVHcloud through the REST endpoint instead of embedding database credentials in the app.
Read the PostgreSQL guideOVHcloud to Power BI
Power Query M
Paste the generated Power Query M into the Power BI Advanced Editor and the report reads live OVHcloud results over HTTPS — no ODBC driver, no database port opened.
How Power BI works no OVHcloud walkthrough written yetOVHcloud alerts and reports
Slack · Discord · Email · Webhook
Put a OVHcloud 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 OVHcloud walkthrough written yetHow it works
5 steps, no inbound firewall change
Install the Network Agent anywhere that can reach the service. It only makes outbound connections, so no inbound firewall rule is needed.
In the OVHcloud manager open your database service and copy the Service URI.
Paste it into the first field. Host, port, database, username and password are read out of it, and the engine picker follows the scheme.
Check the port. OVHcloud assigns one per service rather than using the engine default, so it is worth a glance even when pasting.
Leave Use SSL on, test, and save. Read it from Microsoft Excel, Google Sheets, Power BI, MCP or REST.
Feature deep-dive
What OVHcloud gives you
Aiven underneath, which explains the defaults
If you have used Aiven directly, this card will look familiar. If you have not, the defaults look arbitrary until you know why.
- The default username is avnadmin, not something OVH-flavoured. That is Aiven's convention, showing through — the card prefills it because it is usually right.
- The default database is defaultdb, again Aiven's. And the connection string OVH calls a Service URI is Aiven's term for it too.
- The port is assigned per service rather than being 5432 or 3306, which is also how Aiven does it. Copy it from the manager rather than assuming.
- The one Aiven feature that does not come through is the pooler. Aiven exposes PgBouncer connection pools on its own platform; OVHcloud does not surface them, so there is no pooled endpoint to choose and nothing to configure.
Two regions, two hostname endings
A small thing that matters when you are checking whether the card recognised your host.
- European services end in .database.cloud.ovh.net and US services end in .database.cloud.ovh.us. The card knows both.
- Recognition is what drives the OVHcloud badge and, on PostgreSQL, the forced encryption described below. Either ending gets you both.
- A hostname shaped like postgresql-abc-123.database.cloud.ovh.net is the usual form.
- Nothing else changes between the two regions from the agent's point of view — the same connection, the same driver, the same guarantees.
One card, two engines, and they differ on encryption
The engine picker at the top changes more than the driver, and this is the part worth reading before you clear a checkbox.
- Pick PostgreSQL and the agent forces encryption for either OVHcloud hostname ending, whatever the checkbox says. OVHcloud requires sslmode=require and the agent will not send cleartext there.
- Pick MySQL and the checkbox is the whole mechanism. It is on by default and the connection is encrypted while it stays on, but nothing overrides it if you turn it off.
- The reason is structural rather than an oversight: the agent keeps a table of hosted PostgreSQL hostnames it forces TLS for, and there is no MySQL equivalent. The same split applies on every multi-engine card here.
- The practical instruction is the same either way — leave Use SSL on. On MySQL it is the only thing protecting the connection.
- In neither case is the certificate chain verified. Read encryption as protection against anyone reading the traffic, not as proof of which server answered.
- Everything the agent runs is read-only, and your credentials never leave the machine it runs on.
-- Read-only, whichever engine you picked\nSELECT c.name,\n COUNT(o.id) AS orders,\n SUM(o.amount) AS revenue\nFROM customers AS c\nJOIN orders AS o ON o.customer_id = c.id\nWHERE o.placed_at >= now() - interval '30 days'\nGROUP BY c.name\nORDER 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 OVHcloud to the rest of your data
One statement can span OVHcloud 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 ovh_db.public.orders1 f
JOIN erp_sql.dbo.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 OVHcloud needs
- Host
- postgresql-abc-123.database.cloud.ovh.net in Europe, or .database.cloud.ovh.us in the US. The card recognises both
- Port
- Assigned per service and left blank on purpose — copy it from the OVHcloud manager
- Engines
- PostgreSQL or MySQL, chosen at the top of the card. A pasted Service URI sets it for you
- Driver
- Npgsql or MySqlConnector, carried by the agent — nothing to install at the OVH end
- Paste format
- The Service URI from the manager, as a postgres:// or mysql:// URI
- Defaults
- User avnadmin and database defaultdb, both inherited from Aiven underneath
- TLS
- Forced by the agent for both OVHcloud hostname endings on PostgreSQL. Checkbox-controlled on MySQL, on by default — leave it on. The certificate chain is not verified either way
- Pooling
- None. OVHcloud does not expose Aiven's PgBouncer pools, so there is no pooled endpoint to pick
- Saved as
- PostgreSQL or MySQL, with OVHcloud kept as a badge
- Default schema
- public on PostgreSQL. A MySQL connection is qualified by its database instead
The Aiven lineage is worth knowing mainly because it makes the card predictable. Once you know avnadmin and defaultdb are Aiven conventions rather than OVH quirks, the prefilled values stop looking like guesses and the per-service port stops looking like an oversight. It also sets the right expectation in the other direction: this is Aiven's engine with OVH's control panel and OVH's regions, not a full pass-through of everything Aiven offers.
The pooler is the clearest example of that. On Aiven directly you would choose between a direct connection and a PgBouncer pool, and picking correctly matters. Here the choice does not exist, which is one fewer thing to get wrong.
For a cross-source query the qualifier follows the engine rather than the badge. A PostgreSQL connection you called ovh_db is written ovh_db.public.orders; the same connection on MySQL is qualified by its database instead. Either joins to a folder of CSVs, an on-premises system of record or a billing API in one read-only statement.
Vendor documentation: www.ovhcloud.com
FAQ
Questions about OVHcloud Managed Databases
Which tools can read OVHcloud Managed Databases 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 OVHcloud Managed Databases 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 OVHcloud Managed Databases?
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 OVHcloud Managed Databases?
A reachable host, a role and its password — the agent carries the driver, so nothing is installed on the database. Host: postgresql-abc-123.database.cloud.ovh.net in Europe, or .database.cloud.ovh.us in the US. The card recognises both. Port: Assigned per service and left blank on purpose — copy it from the OVHcloud manager. Engines: PostgreSQL or MySQL, chosen at the top of the card. A pasted Service URI sets it for you. Driver: Npgsql or MySqlConnector, carried by the agent — nothing to install at the OVH end.
Can I join OVHcloud Managed Databases to another database in the same query?
Yes — that is a federated query. One statement can reference OVHcloud Managed Databases 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 OVHcloud Managed Databases different from connecting PostgreSQL?
Only the connection string. OVHcloud Managed Databases speaks the PostgreSQL wire protocol, so filters, scheduling, sharing, the Excel and Google Sheets add-ons and the MCP server all behave identically. The OVHcloud card pre-fills the host, port and SSL settings that provider expects.
Is there a OVHcloud to Excel guide?
Yes — it is the PostgreSQL guide, and it is correct for OVHcloud Managed Databases as written. OVHcloud speaks the PostgreSQL wire protocol, so OVHcloud to Excel, OVHcloud to Google Sheets and every other destination follow the same steps. The only OVHcloud-specific part is the connection string, and the OVHcloud card fills that in for you.
Put OVHcloud 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

