Vultr Managed Databases logo

Managed · PG + MySQL speaks PostgreSQL / MySQL

Connect Vultr Managed Databases to Excel, Google Sheets, AI and REST

Vultr Managed Databases — PostgreSQL or MySQL. The port is assigned per cluster and it is not 5432, which is most of the setup story.

Start free 13 destinations

One connection, every surface

Where your Vultr data can go

Vultr Managed Databases live tables · read-only
Federated queries + any other connector · one SQL across sources · every plan
Network Agent
  • 1 outbound connection
  • 0 inbound ports
  • read-only · credentials stay put

runs on

Query Streams reads Vultr Managed Databases from Microsoft Excel, Google Sheets, Power BI, AI assistants over MCP and a REST endpoint through one read-only connection. One card covers both engines Vultr offers, PostgreSQL and MySQL, and you pick which at the top. Two things are worth knowing before you start: Vultr assigns a non-standard port per cluster rather than using the engine default, and the two engines get different treatment on encryption. Both are covered below.

Vultr Managed Databases is PostgreSQL / MySQL on the wire — the standard driver, so every guide below applies unchanged. The only Vultr-specific part is the connection string, covered under connection details.

  1. For your team, vendors and partners

  2. Vultr to Excel Microsoft Excel · Excel add-in

    Pull live Vultr results straight into a worksheet and refresh them on demand — desktop Excel, Excel Online, Microsoft 365.

    PostgreSQL guide

  3. Vultr to Google Sheets Sheets add-on

    Run a saved Vultr query from the sidebar and drop the rows into the sheet. Shared collaborators can refresh it themselves.

    PostgreSQL guide

  4. Ask Nova about Vultr Nova AI · text to SQL

    Ask a question in plain English. Nova already knows your Vultr tables, writes and runs the SQL, explains the answer and charts it — no query to write, no credentials to hand over.

    How Nova works

  5. Vultr to Data Viewer result sharing · team, vendors, partners · phone, tablet, desktop

    Share a live Vultr result with anyone — a colleague, a vendor, a partner — as a bookmarkable grid that re-runs fresh when opened, on a phone, a tablet or a desktop. They see the results, never the SQL or the credentials.

    How the Data Viewer works
  6. For apps and systems

  7. Vultr REST API HTTP endpoint

    Publish a Vultr 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.

    PostgreSQL guide

  8. Vultr to Power BI Power Query M

    Paste the generated Power Query M into the Power BI Advanced Editor and the report reads live Vultr results over HTTPS — no ODBC driver, no database port opened.

    How Power BI works

  9. Vultr to Airtable Automation platform

    Sync Vultr rows into an Airtable base on a schedule, or fetch them inside an Airtable automation script.

    PostgreSQL guide

  10. Vultr to Baserow Automation platform

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

    PostgreSQL guide

  11. Vultr to SeaTable Automation platform

    Keep a SeaTable base current with Vultr data without exporting a file or exposing the database.

    PostgreSQL guide

  12. Vultr to Smartsheet Automation platform

    Push Vultr results into a Smartsheet grid so plans and reports read from the source system, not last week's export.

    PostgreSQL guide

  13. Vultr to Anvil Anvil Works · App platform

    Back an Anvil Python app with Vultr through the REST endpoint instead of embedding database credentials in the app.

    PostgreSQL guide
  14. For AI tools

  15. Vultr MCP server Claude, Cursor and MCP clients

    Give an AI assistant read-only access to Vultr with the schema it needs to write correct SQL — no credentials in the chat.

    PostgreSQL guide
  16. Delivered to people

  17. Vultr alerts and reports Slack · Discord · Email · Webhook

    Put a Vultr 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

How it works

5 steps, no inbound firewall change

01

Install the Network Agent anywhere that can reach the cluster. It only makes outbound connections, so no inbound firewall rule is needed.

02

In the Vultr portal open Managed Databases, pick your cluster, then Overview and Connection Details.

03

Paste the connection string into the first field. Host, port, database, username and password are read out of it, and the engine picker follows the scheme — a postgres:// string selects PostgreSQL, a mysql:// string selects MySQL.

04

Check the port that landed. Vultr assigns one per cluster and PostgreSQL is often 16751, so this is the field to verify rather than assume.

05

Leave Use SSL on, test, and save. Read it from Microsoft Excel, Google Sheets, Power BI, MCP or REST.

Feature deep-dive

What Vultr gives you

The port is per cluster, and it is the field that catches people

Most managed providers keep the engine default. Vultr does not, and everything downstream depends on getting it right.

  • PostgreSQL clusters are commonly on 16751 rather than 5432, and MySQL clusters get their own assigned port too. The number belongs to the cluster, not the engine.
  • So the card deliberately leaves the port blank rather than prefilling a default that would be wrong. It has to be typed or pasted, and it refuses to save without one.
  • That is the better failure. A wrong-but-plausible 5432 would sail through the form and then time out on connect, which reads as a blocked firewall and sends you looking in entirely the wrong place.
  • Pasting the connection string from Connection Details is the reliable route, because the port travels inside it.

One card, two engines, and they differ on encryption

The engine picker at the top changes more than the driver. This is the part worth reading before you clear a checkbox.

  • Pick PostgreSQL and the agent forces encryption for any .vultrdb.com host, whatever the checkbox says. Vultr requires it, and the agent will not send cleartext to that hostname.
  • 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 difference 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.

What the connection can and cannot do

The same guarantees apply on both engines.

  • Everything the agent runs is read-only, one statement at a time, and it will not run anything that writes.
  • Credentials stay on the machine you installed the agent on. Query Streams keeps no copy of them and no copy of your data.
  • You can share the ability to run a saved query without sharing the SQL behind it or the database password.
  • Whichever engine you picked, the connection is saved as that engine with Vultr kept as a badge.
-- 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 Vultr to the rest of your data

One statement can span Vultr 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

Vultr Managed Databases Managed · PG + MySQL
Microsoft SQL Server 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     vultr_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 Vultr needs

Host
db-postgresql-abc123.vultrdb.com — the card recognises the .vultrdb.com suffix
Port
Assigned per cluster and left blank on purpose. PostgreSQL is often 16751; copy the real one from the portal
Engines
PostgreSQL or MySQL, chosen at the top of the card. A pasted connection string sets it for you
Driver
Npgsql or MySqlConnector, carried by the agent — nothing to install at the Vultr end
Paste format
The string from Overview, Connection Details, as a postgres:// or mysql:// URI
Defaults
Database defaultdb and user vultradmin are prefilled, matching what Vultr creates
TLS
Forced by the agent for .vultrdb.com on PostgreSQL. Checkbox-controlled on MySQL, on by default — leave it on. The certificate chain is not verified either way
Pooling
None. Vultr exposes no pooler and the agent applies no pooler adaptations
Saved as
PostgreSQL or MySQL, with Vultr kept as a badge
Default schema
public on PostgreSQL. A MySQL connection is qualified by its database instead

The non-standard port is the one thing to carry away from this page. It is a small detail that produces a disproportionately confusing failure, because a connection to the right host on the wrong port is not refused — it hangs and then times out, which looks exactly like a blocked firewall. Copying the connection string rather than typing the host by hand avoids the whole class of problem, since the port rides along inside it.

The per-engine encryption difference is worth stating plainly because the checkbox looks identical on both. On PostgreSQL it is a belt-and-braces control over something the agent already guarantees; on MySQL it is the guarantee. Same widget, different weight, and the honest instruction is the same for both.

For a cross-source query the qualifier follows the engine rather than the badge. A PostgreSQL connection you called vultr_db is written vultr_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.vultr.com

FAQ

Questions about Vultr Managed Databases

Which tools can read Vultr 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 Vultr 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 Vultr 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 Vultr Managed Databases?

A reachable host, a role and its password — the agent carries the driver, so nothing is installed on the database. Host: db-postgresql-abc123.vultrdb.com — the card recognises the .vultrdb.com suffix. Port: Assigned per cluster and left blank on purpose. PostgreSQL is often 16751; copy the real one from the portal. Engines: PostgreSQL or MySQL, chosen at the top of the card. A pasted connection string sets it for you. Driver: Npgsql or MySqlConnector, carried by the agent — nothing to install at the Vultr end.

Can I join Vultr Managed Databases to another database in the same query?

Yes — that is a federated query. One statement can reference Vultr 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 Vultr Managed Databases different from connecting PostgreSQL?

Only the connection string. Vultr 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 Vultr card pre-fills the host, port and SSL settings that provider expects.

Is there a Vultr to Excel guide?

Yes — it is the PostgreSQL guide, and it is correct for Vultr Managed Databases as written. Vultr speaks the PostgreSQL wire protocol, so Vultr to Excel, Vultr to Google Sheets and every other destination follow the same steps. The only Vultr-specific part is the connection string, and the Vultr card fills that in for you.

Put Vultr where the work happens

Install the agent, point it at your database, and pick a destination.

Start free All connectors

Read-only Outbound only Credentials stay on the agent