Kompatibel dengan Postgres speaks PostgreSQL
Connect Google AlloyDB to Excel, Sheets and AI
AlloyDB for PostgreSQL over a private IP inside your VPC, or through the AlloyDB Auth Proxy. No public IP, no inbound rule.
One connection, every surface
Where your AlloyDB data can go
Connect AlloyDB 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.
AlloyDB to Excel
Microsoft Excel · Excel add-in
Pull live AlloyDB results straight into a worksheet and refresh them on demand — desktop Excel, Excel Online, Microsoft 365.
Read the PostgreSQL guideAlloyDB to Google Sheets
Sheets add-on
Run a saved AlloyDB query from the sidebar and drop the rows into the sheet. Shared collaborators can refresh it themselves.
Read the PostgreSQL guideAlloyDB MCP server
Claude, Cursor and MCP clients
Give an AI assistant read-only access to AlloyDB with the schema it needs to write correct SQL — no credentials in the chat.
Read the PostgreSQL guideAlloyDB REST API
HTTP endpoint
Publish a AlloyDB 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 guideAlloyDB to Airtable
Automation platform
Sync AlloyDB rows into an Airtable base on a schedule, or fetch them inside an Airtable automation script.
Read the PostgreSQL guideAlloyDB to Baserow
Automation platform
Feed a Baserow table from AlloyDB over the REST endpoint — self-hosted or Baserow cloud.
Read the PostgreSQL guideAlloyDB to SeaTable
Automation platform
Keep a SeaTable base current with AlloyDB data without exporting a file or exposing the database.
Read the PostgreSQL guideAlloyDB to Smartsheet
Automation platform
Push AlloyDB results into a Smartsheet grid so plans and reports read from the source system, not last week's export.
Read the PostgreSQL guideAlloyDB to Anvil
Anvil Works · App platform
Back an Anvil Python app with AlloyDB through the REST endpoint instead of embedding database credentials in the app.
Read the PostgreSQL guideAlloyDB to Power BI
Power Query M
Paste the generated Power Query M into the Power BI Advanced Editor and the report reads live AlloyDB results over HTTPS — no ODBC driver, no database port opened.
How Power BI works no AlloyDB walkthrough written yetAlloyDB alerts and reports
Slack · Discord · Email · Webhook
Put a AlloyDB 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 AlloyDB walkthrough written yetCara kerjanya
5 steps, no inbound firewall change
Put the Network Agent on a VM inside the same Google Cloud VPC as the AlloyDB instance. This is the placement the whole design assumes.
Enter the instance's private IP address. There is no hostname for AlloyDB — the address is what you have.
Or run the AlloyDB Auth Proxy on the agent's VM and point the card at 127.0.0.1. The card recognises localhost and offers the right advice for it.
Fill in the database user and password. AlloyDB defaults to a database called postgres, which the card prefills.
Save. Microsoft Excel, Google Sheets, Power BI, MCP and REST all read through that one connection, or join it to your other sources in a single read-only statement.
Feature deep-dive
What AlloyDB gives you
An agent in the VPC is the whole design
AlloyDB is built to be private, and the Network Agent is built to make only outbound connections. Those two facts fit together neatly enough that the private path is the default rather than the hardened option.
- Run the agent on a VM in the same VPC and it reaches the instance over its private IP. Nothing about AlloyDB is published, and no public IP is needed.
- The agent dials out and never listens, so there is no ingress rule to add and nothing for anyone outside the VPC to reach.
- Because AlloyDB is addressed by IP rather than by hostname, there is nothing in the address for Query Streams to recognise. The AlloyDB badge comes from choosing this card, not from sniffing the address — so a plain Postgres connection to the same IP stays labelled as plain Postgres.
- AlloyDB is PostgreSQL-compatible and nothing else. Unlike Cloud SQL, which also offers MySQL and SQL Server, there is one engine here and no engine picker.
Through the Auth Proxy, turn SSL off
The other supported path is Google's AlloyDB Auth Proxy, and it changes one answer on the form.
- Run the proxy on the agent's machine and point the card at 127.0.0.1. The card notices localhost and says what to do next.
- The proxy encrypts the tunnel itself. Asking the Postgres driver to negotiate its own TLS on top of that is what produces the SSL error people hit here, so clear the checkbox for a proxied connection.
- On a direct private-IP connection, leave the checkbox on. AlloyDB is the exception among hosted providers here — the checkbox genuinely controls whether TLS is used, rather than being overridden by the agent.
- When TLS is on, the traffic is encrypted but the certificate chain is not verified.
Ordinary Postgres once connected
There is no AlloyDB-specific machinery past the address and the proxy. What arrives is Postgres.
- The connection is saved as PostgreSQL with AlloyDB kept as the badge. There is no connection type called AlloyDB.
- Authentication is a database username and password. Google Cloud IAM database authentication is not supported by this card.
- There is no pooler configuration and no pooled endpoint to choose. The agent connects directly.
- public is the default schema, and it is what a cross-source reference carries.
-- Ordinary Postgres, read-only, over the private IP
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
- Hanya untuk keberangkatan — 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.
- Hanya baca, diberlakukan — 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 AlloyDB to the rest of your data
One statement can span AlloyDB 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
PILIH c.region, COUNT(*) AS orders, SUM(i.amount_due) AS invoiced
DARI alloy_core.public.orders1 f
GABUNG erp_sql.dbo.customers2 c ON c.id = f.customer_id
GABUNG penagihan.stripe.invoices3 i ON i.customer = c.stripe_id
KELOMPOKKAN BERDASARKAN c.region
PESAN OLEH 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. Cara kerja kueri terfederasi
Connection details
What AlloyDB needs
- Address
- The instance's private IP. AlloyDB has no public hostname — or 127.0.0.1 when using the Auth Proxy
- Pelabuhan
- 5432
- Driver
- Npgsql, carried by the agent — nothing to install at the AlloyDB end
- Agent placement
- A VM in the same VPC. Outbound only, so no ingress rule and no public exposure
- Basis data
- postgres by default, and prefilled as such
- Authentication
- Database username and password. IAM database authentication is not supported
- TLS
- Controlled by the checkbox and on by default. Encrypted; the certificate chain is not verified. Turn it off when going through the Auth Proxy, which encrypts the tunnel itself
- Pooling
- None to configure — the agent connects directly
- Engines
- PostgreSQL only. Unlike Cloud SQL there is no MySQL or SQL Server option
- Default schema
- public, which is what a federated reference carries
AlloyDB is the clearest case in this catalogue of the agent's shape matching the database's. AlloyDB wants to live on a private IP with no public surface; the agent only ever makes outbound connections and never listens on anything. Put one inside the VPC with the other and there is no compromise to negotiate — no public IP to enable, no authorised-network list to maintain, no ingress rule for someone to audit later. Reaching a private database usually costs you something on the network side. Here it costs a small VM.
The Auth Proxy footnote is worth reading before you hit the error rather than after. Google's proxy already encrypts the tunnel, so when the Postgres driver tries to negotiate TLS inside it as well, the connection test fails with an SSL error that looks like a certificate problem and is not one. Clearing the SSL checkbox for a proxied connection is the fix, and the card says so as soon as it sees a localhost address. On a direct private-IP connection the checkbox should stay on — and unlike most hosted providers here, on AlloyDB it is the checkbox that decides, not the agent.
For a cross-source query AlloyDB is ordinary Postgres. A connection you called alloy_core is written alloy_core.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. The join runs from wherever the agent is, which for AlloyDB means from inside your VPC.
Vendor documentation: cloud.google.com
FAQ
Questions about Google AlloyDB
Which tools can read Google AlloyDB 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 Google AlloyDB 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 Google AlloyDB?
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 Google AlloyDB?
A reachable host, a role and its password — the agent carries the driver, so nothing is installed on the database. Address: The instance's private IP. AlloyDB has no public hostname — or 127.0.0.1 when using the Auth Proxy. Port: 5432. Driver: Npgsql, carried by the agent — nothing to install at the AlloyDB end. Agent placement: A VM in the same VPC. Outbound only, so no ingress rule and no public exposure.
Can I join Google AlloyDB to another database in the same query?
Yes — that is a federated query. One statement can reference Google AlloyDB 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 Google AlloyDB different from connecting PostgreSQL?
Only the connection string. Google AlloyDB speaks the PostgreSQL wire protocol, so filters, scheduling, sharing, the Excel and Google Sheets add-ons and the MCP server all behave identically. The AlloyDB card pre-fills the host, port and SSL settings that provider expects.
Is there a AlloyDB to Excel guide?
Yes — it is the PostgreSQL guide, and it is correct for Google AlloyDB as written. AlloyDB speaks the PostgreSQL wire protocol, so AlloyDB to Excel, AlloyDB to Google Sheets and every other destination follow the same steps. The only AlloyDB-specific part is the connection string, and the AlloyDB card fills that in for you.
Put AlloyDB where the work happens
Install the agent, point it at your database, and pick a destination.
Hanya baca Hanya untuk keberangkatan Credentials stay on the agent

