Managed Postgres speaks PostgreSQL
Connect Render to Excel, Sheets and AI
Render managed Postgres. Use the external connection string — the internal one only resolves inside Render.
One connection, every surface
Where your Render data can go
Connect Render 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.
Render to Excel
Microsoft Excel · Excel add-in
Pull live Render results straight into a worksheet and refresh them on demand — desktop Excel, Excel Online, Microsoft 365.
Read the PostgreSQL guide
Render to Google Sheets
Sheets add-on
Run a saved Render query from the sidebar and drop the rows into the sheet. Shared collaborators can refresh it themselves.
Read the PostgreSQL guide
Render MCP server
Claude, Cursor and MCP clients
Give an AI assistant read-only access to Render with the schema it needs to write correct SQL — no credentials in the chat.
Read the PostgreSQL guide
Render REST API
HTTP endpoint
Publish a Render 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
Render to Airtable
Automation platform
Sync Render rows into an Airtable base on a schedule, or fetch them inside an Airtable automation script.
Read the PostgreSQL guide
Render to Baserow
Automation platform
Feed a Baserow table from Render over the REST endpoint — self-hosted or Baserow cloud.
Read the PostgreSQL guide
Render to SeaTable
Automation platform
Keep a SeaTable base current with Render data without exporting a file or exposing the database.
Read the PostgreSQL guide
Render to Smartsheet
Automation platform
Push Render results into a Smartsheet grid so plans and reports read from the source system, not last week's export.
Read the PostgreSQL guide
Render to Anvil
Anvil Works · App platform
Back an Anvil Python app with Render through the REST endpoint instead of embedding database credentials in the app.
Read the PostgreSQL guide
Render to Power BI
Power Query M
Paste the generated Power Query M into the Power BI Advanced Editor and the report reads live Render results over HTTPS — no ODBC driver, no database port opened.
How Power BI works no Render walkthrough written yet
Render alerts and reports
Slack · Discord · Email · Webhook
Put a Render 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 Render walkthrough written yetHow it works
5 steps, no inbound firewall change
Install the Network Agent on a machine that can reach the internet. It opens one outbound connection and never listens, so Render sees an ordinary client and your network needs no inbound rule.
Open the database in the Render dashboard and find the Connections panel. Copy the External Database URL, not the internal one — this is the step worth slowing down for.
Paste it into the first field. Host, port, database, username and password are read out of it and filled in for you.
Leave Use SSL on and run the test. Render requires encryption on external connections and the agent enforces it for Render hostnames anyway.
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 Render gives you
Internal and external are not interchangeable
Render publishes both addresses on the same page, one above the other, and only one of them can work from outside Render.
- The external hostname ends in -postgres.render.com and is reachable from anywhere. That is the one the agent needs.
- The internal hostname is short and has no domain suffix. It resolves only inside Render's private network, so from your own machine it does not resolve at all.
- The card will accept an internal address without complaining — it checks that you pasted a postgres:// string, not which of Render's two strings it was. If a test fails with a name that cannot be resolved, this is almost always why.
- The fix takes seconds: go back to the Connections panel, copy the External Database URL and re-paste over the top. Nothing else about the connection changes.
Encrypted, and what that does and does not prove
Render requires TLS on external connections, and the agent does not leave that to a checkbox.
- TLS is forced for Render hostnames. Clearing the SSL checkbox does not produce an unencrypted connection; the agent requires encryption regardless of what the box says.
- 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.
- There is no pooler in this path. The agent applies no pooler adaptations for Render, so prepared statements and session handling behave exactly as they would against any ordinary Postgres.
- Everything the agent runs is read-only, and your credentials stay on the machine you installed it on. Query Streams keeps no copy of the data and no copy of the password.
-- Ordinary Postgres, read-only, over TLS
SELECT c.name,
COUNT(o.id) AS orders,
SUM(o.amount) AS revenue
FROM public.customers AS c
JOIN public.orders AS o ON o.customer_id = c.id
WHERE o.placed_at >= now() - interval '30 days'
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 Render to the rest of your data
One statement can span Render 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 render_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 Render needs
- Host
- dpg-<id>-a.<region>-postgres.render.com — the external name; internal names do not resolve from outside Render
- Port
- 5432
- Driver
- Npgsql, carried by the agent — nothing to install at the Render end
- Paste format
- The External Database URL from the database's Connections panel, as a postgres:// URI
- TLS
- Required and enforced for Render hostnames. Encrypted; the certificate chain is not verified
- Pooling
- None. The agent applies no pooler adaptations for Render
- Saved as
- PostgreSQL, with Render kept as a badge
- Default schema
- public, which is what a federated reference carries
Render is a straightforward Postgres connection with one thing standing between you and it, and that thing is a copy-and-paste choice rather than anything technical. Both URLs are valid Postgres strings, both start with postgres://, and the difference between them is a hostname suffix most people do not read. Knowing to take the external one turns the only likely failure into a non-event.
The reason the internal address exists at all is that services running inside Render should use it — it stays on Render's private network and does not make a round trip out and back. That logic is correct and has nothing to do with you, because the Network Agent runs on your infrastructure. If you happen to run the agent on a Render service yourself, the internal address becomes the right answer for the same reason.
For a cross-source query Render is ordinary Postgres. A connection you called render_app is written render_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: render.com
Same wire protocol
These connect the same way
They share every guide above; only the connection string differs.
FAQ
Questions about Render
Which tools can read Render 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 Render 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 Render?
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 Render?
A reachable host, a role and its password — the agent carries the driver, so nothing is installed on the database. Host: dpg-<id>-a.<region>-postgres.render.com — the external name; internal names do not resolve from outside Render. Port: 5432. Driver: Npgsql, carried by the agent — nothing to install at the Render end. Paste format: The External Database URL from the database's Connections panel, as a postgres:// URI.
Can I join Render to another database in the same query?
Yes — that is a federated query. One statement can reference Render 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 Render different from connecting PostgreSQL?
Only the connection string. Render speaks the PostgreSQL wire protocol, so filters, scheduling, sharing, the Excel and Google Sheets add-ons and the MCP server all behave identically. The Render card pre-fills the host, port and SSL settings that provider expects.
Is there a Render to Excel guide?
Yes — it is the PostgreSQL guide, and it is correct for Render as written. Render speaks the PostgreSQL wire protocol, so Render to Excel, Render to Google Sheets and every other destination follow the same steps. The only Render-specific part is the connection string, and the Render card fills that in for you.
Put Render 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