Managed Postgres speaks PostgreSQL
Connect Fly.io Postgres to Excel, Sheets and AI
Fly.io Managed Postgres. Reachability is the question worth settling first — there are three answers and all of them work.
One connection, every surface
Where your Fly.io data can go
Connect Fly.io 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.
Fly.io to Excel
Microsoft Excel · Excel add-in
Pull live Fly.io results straight into a worksheet and refresh them on demand — desktop Excel, Excel Online, Microsoft 365.
Read the PostgreSQL guide
Fly.io to Google Sheets
Sheets add-on
Run a saved Fly.io query from the sidebar and drop the rows into the sheet. Shared collaborators can refresh it themselves.
Read the PostgreSQL guide
Fly.io MCP server
Claude, Cursor and MCP clients
Give an AI assistant read-only access to Fly.io with the schema it needs to write correct SQL — no credentials in the chat.
Read the PostgreSQL guide
Fly.io REST API
HTTP endpoint
Publish a Fly.io 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 guide
Fly.io to Airtable
Automation platform
Sync Fly.io rows into an Airtable base on a schedule, or fetch them inside an Airtable automation script.
Read the PostgreSQL guide
Fly.io to Baserow
Automation platform
Feed a Baserow table from Fly.io over the REST endpoint — self-hosted or Baserow cloud.
Read the PostgreSQL guide
Fly.io to SeaTable
Automation platform
Keep a SeaTable base current with Fly.io data without exporting a file or exposing the database.
Read the PostgreSQL guide
Fly.io to Smartsheet
Automation platform
Push Fly.io results into a Smartsheet grid so plans and reports read from the source system, not last week's export.
Read the PostgreSQL guide
Fly.io to Anvil
Anvil Works · App platform
Back an Anvil Python app with Fly.io through the REST endpoint instead of embedding database credentials in the app.
Read the PostgreSQL guide
Fly.io to Power BI
Power Query M
Paste the generated Power Query M into the Power BI Advanced Editor and the report reads live Fly.io results over HTTPS — no ODBC driver, no database port opened.
How Power BI works no Fly.io walkthrough written yet
Fly.io alerts and reports
Slack · Discord · Email · Webhook
Put a Fly.io 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 Fly.io walkthrough written yetHow it works
5 steps, no inbound firewall change
Decide where the agent runs. On a Fly Machine in the same organisation it reaches the database directly; anywhere else, run fly mpg proxy and point the connection at 127.0.0.1. Either way the agent only makes outbound connections.
Get the connection string from fly mpg connect or the dashboard. Paste it into the first field and host, port, database, username and password are read out of it.
Check the hostname you ended up with. direct.<cluster>.flympg.net is the database itself and pgbouncer.<cluster>.flympg.net is the pooled endpoint — the mode is in the prefix, not the port.
Leave Use SSL on for a flympg.net host. Turn it off only when you are going through a local fly mpg proxy tunnel, where the traffic never leaves your machine.
Test, save, then read it from Microsoft Excel, Google Sheets, Power BI, MCP or REST. The pasted string is dropped once the fields are filled, so the password is stored once.
Feature deep-dive
What Fly.io gives you
Three ways in, and the card tells you when you have picked a fourth
Fly MPG assumes its clients live on Fly. The agent usually does not, so this is the one decision worth making before anything else.
- Agent on a Fly Machine in the same organisation — the database is simply reachable, and this is the tidiest answer if you already run things on Fly.
- Agent on your own hardware, through fly mpg proxy — Fly opens a local tunnel and you connect to 127.0.0.1 on the proxy port. This is the usual answer for an on-premises agent.
- Agent anywhere, straight to the flympg.net hostname — works when your network can reach it, and times out when it cannot. If a direct connection hangs rather than being refused, this is the case you are in, and the proxy is the fix.
- What does not work is a .internal hostname. Those are Fly's private 6PN names and they resolve only inside Fly's network, so the card rejects them by name rather than letting the connection die as a timeout — the same courtesy the Railway card extends to its private variable.
The pooled endpoint is a hostname prefix, which is unusually easy to get right
Most services with a pooler give it a separate port or a separate flag. Fly changes one word at the front of the hostname.
- direct.<cluster>.flympg.net is the database. pgbouncer.<cluster>.flympg.net is the PgBouncer pool, same cluster, same credentials.
- Because the prefix is part of the hostname, it travels with whatever you paste. Paste a pgbouncer URI and the card reads the prefix and records the pooled mode for you — no dropdown to remember.
- Use the direct host for long-running reads and the pool when you have many short ones. Everything the agent runs is read-only either way.
- Worth being precise about what the agent does with that: it records which endpoint you are on, and connects. It does not currently change its driver settings between the two. If you are driving heavy concurrent load through the pool, prefer the direct host for now.
Encryption follows the checkbox here, and that is on purpose
Most managed Postgres cards on this site say the agent forces TLS regardless of the checkbox. This one does not, and the reason is the proxy.
- The SSL checkbox is on by default, and left on you get an encrypted connection to a flympg.net host. That is the normal path and nothing needs changing.
- The agent does not override it, because a local fly mpg proxy tunnel is a legitimate way to connect and forcing encryption would break it. Traffic through that tunnel never leaves your machine, so there is nothing on the wire to protect.
- So the honest instruction is the simple one: leave it on unless you are on 127.0.0.1 through the proxy. Do not clear it for a flympg.net host.
- When encryption is on, the certificate chain is not verified. Read it as protection against anyone reading the traffic in transit, rather than as proof of which server answered.
- Your credentials never leave the machine the agent runs on, and Query Streams stores no copy of your data and no copy of your password.
-- Ordinary Postgres, read-only\nSELECT c.name,\n COUNT(o.id) AS orders,\n SUM(o.amount) AS revenue\nFROM public.customers AS c\nJOIN public.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 Fly.io to the rest of your data
One statement can span Fly.io 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 fly_app.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 Fly.io needs
- Host
- direct.<cluster>.flympg.net or pgbouncer.<cluster>.flympg.net — or 127.0.0.1 through a local fly mpg proxy
- Port
- 5432, or the proxy port when tunnelling
- Driver
- Npgsql, carried by the agent — nothing to install at the Fly end
- Paste format
- The string from fly mpg connect or the dashboard, as a postgresql:// URI
- Defaults
- Database fly-db and user fly-user are prefilled, matching what Fly creates
- TLS
- Follows the SSL checkbox, which is on by default. Not forced by the agent, so that a local proxy tunnel stays possible. Encrypted when on; the certificate chain is not verified
- Pooling
- PgBouncer on the pgbouncer. hostname prefix. The card reads the prefix and records the mode
- Rejected
- .internal hostnames — those are Fly private-network names and do not resolve from outside Fly
- Saved as
- PostgreSQL, with Fly.io kept as a badge
- Default schema
- public, which is what a federated reference carries
Fly.io is the clearest case on this site of the Network Agent's shape being the thing that makes a connection possible rather than merely safe. Fly MPG expects its clients to be on Fly, which is a problem for any tool that connects from its own cloud to yours. The agent does not connect from anywhere — it runs where you put it, including on a Fly Machine inside the same organisation, and dials out. The awkward network position simply stops being awkward.
The hostname-prefix design deserves a word of credit. Putting the pool at pgbouncer.<cluster> rather than on a second port or behind a saved flag means the choice is carried in the address itself, so it survives being copied, pasted and stored without a second setting to keep in step. Crunchy Bridge achieves the same thing with a port. Both are better than a flag, and for the same reason.
For a cross-source query Fly.io is ordinary Postgres. A connection you called fly_app is written fly_app.public.orders, and 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: fly.io
Same wire protocol
These connect the same way
They share every guide above; only the connection string differs.
FAQ
Questions about Fly.io Postgres
Which tools can read Fly.io Postgres 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 Fly.io Postgres 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 Fly.io Postgres?
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 Fly.io Postgres?
A reachable host, a role and its password — the agent carries the driver, so nothing is installed on the database. Host: direct.<cluster>.flympg.net or pgbouncer.<cluster>.flympg.net — or 127.0.0.1 through a local fly mpg proxy. Port: 5432, or the proxy port when tunnelling. Driver: Npgsql, carried by the agent — nothing to install at the Fly end. Paste format: The string from fly mpg connect or the dashboard, as a postgresql:// URI.
Can I join Fly.io Postgres to another database in the same query?
Yes — that is a federated query. One statement can reference Fly.io Postgres 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 Fly.io Postgres different from connecting PostgreSQL?
Only the connection string. Fly.io Postgres speaks the PostgreSQL wire protocol, so filters, scheduling, sharing, the Excel and Google Sheets add-ons and the MCP server all behave identically. The Fly.io card pre-fills the host, port and SSL settings that provider expects.
Is there a Fly.io to Excel guide?
Yes — it is the PostgreSQL guide, and it is correct for Fly.io Postgres as written. Fly.io speaks the PostgreSQL wire protocol, so Fly.io to Excel, Fly.io to Google Sheets and every other destination follow the same steps. The only Fly.io-specific part is the connection string, and the Fly.io card fills that in for you.
Put Fly.io 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
English 
Spanish 
German 
French 
Portuguese 
Japanese 
Korean 
Chinese 
Italian 
Dutch 
Indonesian 
Polish