ホスト型Postgres
Connect スーパーベース to Excel, Sheets and AI
Supabase Postgres, direct or through the Supavisor pooler. A first-class card — not just 'Postgres with extra steps'.
One connection, every surface
Where your Supabase data can go
Connect Supabase 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.
Supabase to Excel
Microsoft Excel · Excel add-in
Pull live Supabase results straight into a worksheet and refresh them on demand — desktop Excel, Excel Online, Microsoft 365.
Read the PostgreSQL guide same steps — only the Supabase connection string differs
Supabase to Google Sheets
Sheets add-on
Run a saved Supabase query from the sidebar and drop the rows into the sheet. Shared collaborators can refresh it themselves.
Read the PostgreSQL guide same steps — only the Supabase connection string differs
Supabase MCP server
Claude, Cursor and MCP clients
Give an AI assistant read-only access to Supabase with the schema it needs to write correct SQL — no credentials in the chat.
Read the PostgreSQL guide same steps — only the Supabase connection string differs
Supabase REST API
HTTP endpoint
Publish a Supabase 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 same steps — only the Supabase connection string differs
Supabase to Airtable
Automation platform
Sync Supabase rows into an Airtable base on a schedule, or fetch them inside an Airtable automation script.
Read the PostgreSQL guide same steps — only the Supabase connection string differs
Supabase to Baserow
Automation platform
Feed a Baserow table from Supabase over the REST endpoint — self-hosted or Baserow cloud.
Read the PostgreSQL guide same steps — only the Supabase connection string differs
Supabase to SeaTable
Automation platform
Keep a SeaTable base current with Supabase data without exporting a file or exposing the database.
Read the PostgreSQL guide same steps — only the Supabase connection string differs
Supabase to Smartsheet
Automation platform
Push Supabase results into a Smartsheet grid so plans and reports read from the source system, not last week's export.
Read the PostgreSQL guide same steps — only the Supabase connection string differs
Supabase to Anvil
Anvil Works · App platform
Back an Anvil Python app with Supabase through the REST endpoint instead of embedding database credentials in the app.
Read the PostgreSQL guide same steps — only the Supabase connection string differs
Supabase to Power BI
Power Query M
Paste the generated Power Query M into the Power BI Advanced Editor and the report reads live Supabase results over HTTPS — no ODBC driver, no database port opened.
How Power BI works no Supabase walkthrough written yet
Supabase alerts and reports
Slack · Discord · Email · Webhook
Put a Supabase 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 Supabase walkthrough written yet仕組み
5 steps, no inbound firewall change
Install the Network Agent anywhere with outbound HTTPS — Supabase is a public endpoint, so no inbound rule and no allow-list is needed.
Copy a connection string from the Supabase dashboard and paste it. Host, port, database and role are read out of it; the string itself is not kept.
Pick the mode. Session pooler is the default and the right answer here, because the agent holds a long-lived connection.
Save. Your tables are read; Supabase's own platform schemas are left out of the listing so the picker is not full of things you did not write.
Write read-only SQL, or let Nova write it. Read the saved query from Excel, Sheets, Power BI, MCP or REST.
Feature deep-dive
What Supabase gives you
Three ways in, and which one to choose
Supabase offers a direct connection and two pooler endpoints, and the choice matters more than it looks. The agent recognises which one you gave it from the host and port, and adapts.
- Session pooler — port 5432 on a pooler.supabase.com host. The default, and the recommendation, because a long-lived connection is exactly what a pooler in session mode is for.
- Transaction pooler — port 6543. Recognised and adjusted for: the session is not reset on close and server-side prepared statements are switched off, because a transaction pooler reassigns the backend between statements and prepared statements do not survive that.
- 直接 — port 5432 on a db.<project>.supabase.co host. Worth knowing that Supabase serves this over IPv6 only unless you have bought the IPv4 add-on. If the agent's network is IPv4-only the connection fails, and the error says so and tells you to use the session pooler rather than leaving you to guess.
- The username shape differs between them — a pooler wants postgres.<project-ref>, direct wants plain postgres — and this is checked as you type rather than at first query.
Your schema, not Supabase's plumbing
A Supabase project carries a good deal of machinery in its own schemas. Left in, they drown the table picker in things nobody wants to report on.
- auth, storage, realtime, supabase_functions, supabase_migrations, pgbouncer and the rest are hidden from listing on a Supabase host.
- The filtering keys off the host, so a plain Postgres server of yours that happens to have a schema called auth keeps it. Nothing is hidden from a database that is not Supabase's.
- public stays the default schema, which is what a cross-source query uses as its middle part.
When the password is refused
The single most common Supabase setup failure has a confusing cause: the dashboard login and the database password are two different things, and the second one is the one this needs. When Postgres refuses the credentials the agent says which of the two you are likely holding rather than passing the raw error through.
-- supabase_app is the connection, public is the Postgres schema
SELECT p.plan, COUNT(*) AS accounts
FROM supabase_app.public.profiles p
JOIN stripe.stripe.subscriptions s ON s.customer_id = p.stripe_id
WHERE s.status = 'active'
GROUP BY p.planShared 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 Supabase to the rest of your data
One statement can span Supabase 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
セレクト c.region, COUNT(*) AS orders, SUM(i.amount_due) AS invoiced
フロム supabase_app.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 Supabase needs
- ポート
- 5432 for direct and the session pooler, 6543 for the transaction pooler
- TLS
- Required, and forced by the agent for any .supabase.co or .pooler.supabase.com host — a pasted string that lost its sslmode still connects encrypted
- データベース
- postgres, unless you renamed it
- 役割
- A database role and its database password — not the dashboard login. A SELECT-only role is the right one to use
- Username shape
- postgres.<project-ref> on a pooler host, plain postgres on the direct host. Checked as you type
- Driver
- Npgsql 9.0.3, carried by the agent — nothing to install at the Supabase end
- Direct host
- IPv6 only unless you have the IPv4 add-on. The session pooler is reachable either way
- Hidden schemas
- auth, storage, realtime, supabase_functions, supabase_migrations, pgbouncer and friends — on Supabase hosts only
- 読み取り専用
- Enforced on the agent before the statement is sent to Supabase
Grant the role SELECT and nothing more — Supabase is ordinary Postgres underneath, so GRANT SELECT ON ALL TABLES IN SCHEMA public plus ALTER DEFAULT PRIVILEGES covers tables you add later. Independently of that grant, the agent refuses any statement that is not a read before it ever reaches Supabase.
Row Level Security still applies. The connection reads as the role you gave it, so if your policies restrict what that role can see, a saved query sees the same subset — which is a reasonable way to scope a reporting connection deliberately.
In a cross-source query the middle part of a three-part reference is public, the Postgres schema. A connection called supabase_app is written supabase_app.public.profiles.
Vendor documentation: supabase.com
Same wire protocol
These connect the same way
They share every guide above; only the connection string differs.
FAQ
Questions about Supabase
Which tools can read Supabase 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 Supabase 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 Supabase?
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 Supabase?
A reachable host, a role and its password — the agent carries the driver, so nothing is installed on the database. Port: 5432 for direct and the session pooler, 6543 for the transaction pooler. TLS: Required, and forced by the agent for any .supabase.co or .pooler.supabase.com host — a pasted string that lost its sslmode still connects encrypted. Database: postgres, unless you renamed it. Role: A database role and its database password — not the dashboard login. A SELECT-only role is the right one to use.
Can I join Supabase to another database in the same query?
Yes — that is a federated query. One statement can reference Supabase 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 there a Supabase to Excel guide?
Yes — it is the PostgreSQL guide, and it is correct for Supabase as written. Supabase speaks the PostgreSQL wire protocol, so Supabase to Excel, Supabase to Google Sheets and every other destination follow the same steps. The only Supabase-specific part is the connection string, and the Supabase card fills that in for you.
Put Supabase where the work happens
Install the agent, point it at your database, and pick a destination.
読み取り専用 発信専用 Credentials stay on the agent
English 
Spanish 
German 
French 
Portuguese 
Japanese 
Korean 
Chinese 
Italian 
Dutch 
Indonesian 
Polish