Managed Postgres speaks PostgreSQL
Connect IBM Cloud Databases for PostgreSQL to Excel, Sheets and AI
IBM Cloud Databases for PostgreSQL. The port is assigned per deployment, so copy it from the Endpoints panel.
One connection, every surface
Where your IBM Cloud data can go
Connect IBM Cloud 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.
IBM Cloud to Excel
Microsoft Excel · Excel add-in
Pull live IBM Cloud results straight into a worksheet and refresh them on demand — desktop Excel, Excel Online, Microsoft 365.
Read the PostgreSQL guideIBM Cloud to Google Sheets
Sheets add-on
Run a saved IBM Cloud query from the sidebar and drop the rows into the sheet. Shared collaborators can refresh it themselves.
Read the PostgreSQL guideIBM Cloud MCP server
Claude, Cursor and MCP clients
Give an AI assistant read-only access to IBM Cloud with the schema it needs to write correct SQL — no credentials in the chat.
Read the PostgreSQL guideIBM Cloud REST API
HTTP endpoint
Publish a IBM Cloud 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 guideIBM Cloud to Airtable
Automation platform
Sync IBM Cloud rows into an Airtable base on a schedule, or fetch them inside an Airtable automation script.
Read the PostgreSQL guideIBM Cloud to Baserow
Automation platform
Feed a Baserow table from IBM Cloud over the REST endpoint — self-hosted or Baserow cloud.
Read the PostgreSQL guideIBM Cloud to SeaTable
Automation platform
Keep a SeaTable base current with IBM Cloud data without exporting a file or exposing the database.
Read the PostgreSQL guideIBM Cloud to Smartsheet
Automation platform
Push IBM Cloud results into a Smartsheet grid so plans and reports read from the source system, not last week's export.
Read the PostgreSQL guideIBM Cloud to Anvil
Anvil Works · App platform
Back an Anvil Python app with IBM Cloud through the REST endpoint instead of embedding database credentials in the app.
Read the PostgreSQL guideIBM Cloud to Power BI
Power Query M
Paste the generated Power Query M into the Power BI Advanced Editor and the report reads live IBM Cloud results over HTTPS — no ODBC driver, no database port opened.
How Power BI works no IBM Cloud walkthrough written yetIBM Cloud alerts and reports
Slack · Discord · Email · Webhook
Put a IBM Cloud 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 IBM Cloud walkthrough written yetHow it works
5 steps, no inbound firewall change
Install the Network Agent on a machine that can reach the deployment — your own network for a private endpoint, anywhere for a public one. It opens one outbound connection and never listens.
In IBM Cloud open the service, then Endpoints, and choose the Public or Private tab to match how the agent will reach it.
Copy the PostgreSQL connection string and paste it into the first field. Host, port, database, username and password are read out of it.
Check the port. IBM assigns one per deployment — often in the 30000s — and this is the field to confirm rather than assume, because 5432 is almost certainly wrong here.
Leave Use SSL on, run the test, and save. Read it from Microsoft Excel, Google Sheets, Power BI, MCP or REST through that one connection.
Feature deep-dive
What IBM Cloud gives you
The port is per deployment, and the card deliberately leaves it blank
Nearly every other Postgres card here prefills 5432 because nearly every other service uses it. This one does not, and the empty field is the point.
- IBM allocates a port to each deployment rather than running everything on the standard one. Two databases in the same account will not share a port.
- So the field starts empty and the card asks for it explicitly. A prefilled 5432 would be wrong far more often than right, and wrong in a way that looks like a network problem rather than a typo.
- Take the port from the same Endpoints panel as the hostname. It is in the connection string IBM gives you, immediately after the host.
- If a saved connection times out rather than being refused, the port is the first thing to re-check against the dashboard.
IBM issues its own certificate authority, and what the agent does about it
This is the honest bit, and it is more specific than the usual TLS paragraph.
- The connection is encrypted, and the agent forces it. TLS is required for IBM Cloud hostnames whether or not the SSL checkbox is ticked.
- The certificate chain is not verified. IBM fronts deployments with a certificate from its own authority, and the agent has no way to be given that authority's certificate to check against.
- IBM's own connection string usually carries sslmode=verify-full. That parameter is not read — the agent takes the host, port, database, username and password out of the string and applies its own TLS setting, which requires encryption without validating the chain.
- Read it as protection against anyone reading the traffic in transit, not as proof of which server answered. If chain verification against IBM's CA matters for your compliance position, this is the detail to note.
-- 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 IBM Cloud to the rest of your data
One statement can span IBM Cloud 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 ibm_prod.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 IBM Cloud needs
- Host
- <id>.databases.appdomain.cloud, from the service's Endpoints panel
- Port
- Assigned per deployment, often in the 30000s. Not 5432, and not prefilled
- Driver
- Npgsql, carried by the agent — nothing to install at the IBM Cloud end
- Paste format
- The PostgreSQL connection string from Endpoints, as a postgres:// URI
- TLS
- Required and enforced for IBM Cloud hostnames. Encrypted; IBM's certificate authority is not verified and no custom CA can be supplied
- Pooling
- None. The agent applies no pooler adaptations for IBM Cloud
- Defaults
- Database ibmclouddb and user admin are prefilled, matching what IBM creates
- Saved as
- PostgreSQL, with IBM Cloud kept as a badge
- Default schema
- public, which is what a federated reference carries
The empty port field is a small design decision worth explaining, because it looks like an omission. Presets exist to prefill the things a provider always does the same way, and IBM's port is precisely not one of those. Filling in a plausible default would produce a connection that passes validation and then fails to connect, which is a worse outcome than an empty field that asks you a question.
On the certificate point: the useful distinction is between encryption and identity. The traffic between the agent and your IBM deployment is encrypted and cannot be read in transit. What the agent does not do is confirm, against IBM's certificate authority, that the server presenting that certificate is the one you meant. For most reporting workloads over a private endpoint that distinction is academic; if it is not academic for you, it is better read here than discovered in an audit.
For a cross-source query IBM Cloud is ordinary Postgres. A connection you called ibm_prod is written ibm_prod.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: www.ibm.com
FAQ
Questions about IBM Cloud Databases for PostgreSQL
Which tools can read IBM Cloud Databases for PostgreSQL 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 IBM Cloud Databases for PostgreSQL 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 IBM Cloud Databases for PostgreSQL?
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 IBM Cloud Databases for PostgreSQL?
A reachable host, a role and its password — the agent carries the driver, so nothing is installed on the database. Host: <id>.databases.appdomain.cloud, from the service's Endpoints panel. Port: Assigned per deployment, often in the 30000s. Not 5432, and not prefilled. Driver: Npgsql, carried by the agent — nothing to install at the IBM Cloud end. Paste format: The PostgreSQL connection string from Endpoints, as a postgres:// URI.
Can I join IBM Cloud Databases for PostgreSQL to another database in the same query?
Yes — that is a federated query. One statement can reference IBM Cloud Databases for PostgreSQL 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 IBM Cloud Databases for PostgreSQL different from connecting PostgreSQL?
Only the connection string. IBM Cloud Databases for PostgreSQL speaks the PostgreSQL wire protocol, so filters, scheduling, sharing, the Excel and Google Sheets add-ons and the MCP server all behave identically. The IBM Cloud card pre-fills the host, port and SSL settings that provider expects.
Is there a IBM Cloud to Excel guide?
Yes — it is the PostgreSQL guide, and it is correct for IBM Cloud Databases for PostgreSQL as written. IBM Cloud speaks the PostgreSQL wire protocol, so IBM Cloud to Excel, IBM Cloud to Google Sheets and every other destination follow the same steps. The only IBM Cloud-specific part is the connection string, and the IBM Cloud card fills that in for you.
Put IBM Cloud 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

