Google AlloyDB 标志

兼容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.

1connection
0inbound ports
只读enforced

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 guide
指导

AlloyDB 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 guide
指导

AlloyDB 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 guide
指导

AlloyDB 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 guide
指导

AlloyDB 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 guide
指导

AlloyDB to Baserow

Automation platform

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

Read the PostgreSQL guide
指导

AlloyDB to SeaTable

Automation platform

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

Read the PostgreSQL guide
指导

AlloyDB 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 guide
指导

AlloyDB 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 guide
支持

AlloyDB 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 yet
支持

AlloyDB 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 yet

工作原理

5 steps, no inbound firewall change

01

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.

02

Enter the instance's private IP address. There is no hostname for AlloyDB — the address is what you have.

03

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.

04

Fill in the database user and password. AlloyDB defaults to a database called postgres, which the card prefills.

05

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

  • 仅限出站 — 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.
  • 只读,强制执行 — 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

Google AlloyDB 兼容Postgres
微软 SQL 服务器 关系引擎
条纹 付款与账单

One statement

-- nothing copied, nothing merged, nothing scheduled
选择   c.region, COUNT(*) AS orders, SUM(i.amount_due) AS invoiced
     alloy_core.public.orders1 f
连接     erp_sql.dbo.customers2    c ON c.id = f.customer_id
连接     计费.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. 联合查询的工作原理

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
港口
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
数据库
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.

只读 仅限出站 Credentials stay on the agent