Prisma Postgres logo

Serverless Postgres speaks PostgreSQL

Connect Prisma Postgres to Excel, Google Sheets, AI and REST

Prisma Postgres over a direct TCP connection. Every database answers on the same hostname, so the credentials are what identify yours.

One connection, every surface

Where your Prisma data can go

Query Streams reads Prisma Postgres from Microsoft Excel, Google Sheets, Power BI, AI assistants over MCP and a REST endpoint through one read-only connection. Prisma is unusual in two ways worth knowing before you start: every customer's database answers on the same hostname, db.prisma.io, with the credentials deciding which one you reach — and Prisma hands out two different connection strings, only one of which is a real Postgres connection. The card is built around getting you the right one.

Prisma Postgres is PostgreSQL on the wire — the standard driver, so every guide below applies unchanged. The only Prisma-specific part is the connection string, covered under connection details.

  1. For your team, vendors and partners
  2. Prisma to Excel Microsoft Excel · Excel add-in

    Pull live Prisma results straight into a worksheet and refresh them on demand — desktop Excel, Excel Online, Microsoft 365.

    PostgreSQL guide
  3. Prisma to Google Sheets Sheets add-on

    Run a saved Prisma query from the sidebar and drop the rows into the sheet. Shared collaborators can refresh it themselves.

    PostgreSQL guide
  4. Ask Nova about Prisma Nova AI · text to SQL

    Ask a question in plain English. Nova already knows your Prisma tables, writes and runs the SQL, explains the answer and charts it — no query to write, no credentials to hand over.

    How Nova works
  5. Prisma to Data Viewer result sharing · team, vendors, partners · phone, tablet, desktop

    Share a live Prisma result with anyone — a colleague, a vendor, a partner — as a bookmarkable grid that re-runs fresh when opened, on a phone, a tablet or a desktop. They see the results, never the SQL or the credentials.

    How the Data Viewer works
  6. For apps and systems
  7. Prisma REST API HTTP endpoint

    Publish a Prisma 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.

    PostgreSQL guide
  8. Prisma to Power BI Power Query M

    Paste the generated Power Query M into the Power BI Advanced Editor and the report reads live Prisma results over HTTPS — no ODBC driver, no database port opened.

    How Power BI works
  9. Prisma to Airtable Automation platform

    Sync Prisma rows into an Airtable base on a schedule, or fetch them inside an Airtable automation script.

    PostgreSQL guide
  10. Prisma to Baserow Automation platform

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

    PostgreSQL guide
  11. Prisma to SeaTable Automation platform

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

    PostgreSQL guide
  12. Prisma to Smartsheet Automation platform

    Push Prisma results into a Smartsheet grid so plans and reports read from the source system, not last week's export.

    PostgreSQL guide
  13. Prisma to Anvil Anvil Works · App platform

    Back an Anvil Python app with Prisma through the REST endpoint instead of embedding database credentials in the app.

    PostgreSQL guide
  14. For AI tools
  15. Prisma MCP server Claude, Cursor and MCP clients

    Give an AI assistant read-only access to Prisma with the schema it needs to write correct SQL — no credentials in the chat.

    PostgreSQL guide
  16. Delivered to people
  17. Prisma alerts and reports Slack · Discord · Email · Webhook

    Put a Prisma 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

How it works

5 steps, no inbound firewall change

01

Install the Network Agent wherever suits you. It opens one outbound connection and never listens, so Prisma sees an ordinary client and your network needs no inbound rule.

02

In the Prisma Console, generate the direct TCP connection string — the postgres:// one. It is not the same as the Accelerate URL the console shows for application use.

03

Paste it in. Host, port, username and password are read straight out of it.

04

Leave the database as postgres unless you know yours differs. Prisma's string often omits the database name, so the card fills in the usual one.

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 Prisma gives you

Two connection strings, and only one of them is Postgres

This is the thing that catches people, and it catches them because the wrong string looks perfectly reasonable.

  • Prisma Accelerate URLs start with prisma:// or prisma+postgres://. They address Prisma's own connection layer, which speaks its protocol rather than the Postgres wire protocol.
  • Query Streams connects over direct TCP with a standard Postgres driver, so an Accelerate URL cannot work here no matter what credentials it carries.
  • Paste one anyway and the card tells you exactly that, and what to generate instead. It is a specific message rather than a generic parse failure, because the two strings are easy to mix up.
  • The one you want starts with postgres:// or postgresql:// and points at db.prisma.io on 5432.

Everyone shares one hostname

Most managed Postgres services give you a hostname unique to your instance. Prisma does not, and it changes what the fields mean.

  • Every Prisma Postgres database answers on db.prisma.io. There is no per-project or per-region hostname to look up.
  • Your username and password are what select the database. They are generated in the Prisma Console rather than chosen by you, and they are the entire identity of the connection.
  • That makes the credentials worth treating carefully. On most services a leaked password is scoped by an obscure hostname as well; here the hostname is public knowledge.
  • The pasted string is never stored. It is read once to fill the form and then dropped, so the password lives in one place rather than two.

TLS is required and the agent does not leave it to chance

Because the hostname is fixed and known, the agent can be firm about this one.

  • The agent forces TLS for db.prisma.io. The Use SSL checkbox defaults on, and clearing it does not produce an unencrypted connection to a Prisma host.
  • The certificate chain is not verified. Encryption is required; validation of what signed the certificate is not performed, so read it as protection against eavesdropping rather than proof of what you reached.
  • There is no connection pooler on this path. Prisma's pooling story lives in Accelerate, which this card deliberately does not use, so what you get is a direct connection with no pooled mode to choose.
  • Everything downstream is ordinary Postgres: schemas, types, and public as the default schema in a cross-source reference.
-- Ordinary Postgres, read-only, over direct TCP
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 Prisma to the rest of your data

One statement can span Prisma 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

Prisma Postgres Serverless Postgres
Microsoft SQL Server Relational engine
Stripe Payments & billing

One statement

-- nothing copied, nothing merged, nothing scheduled
SELECT   c.region, COUNT(*) AS orders, SUM(i.amount_due) AS invoiced
FROM     prisma_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 Prisma needs

Host
db.prisma.io — the same for every Prisma Postgres database
Port
5432
Driver
Npgsql, carried by the agent — nothing to install at the Prisma end
Paste format
The direct TCP string from the Prisma Console, as a postgres:// URI
Database
postgres by default. Prisma's connection string often leaves it out
Username
Generated in the Prisma Console. It is what selects your database
TLS
Required, and forced by the agent for db.prisma.io. Encrypted; the certificate chain is not verified
Pooling
None. The agent applies no pooler adaptations for Prisma
Not this card
Prisma Accelerate URLs on prisma:// or prisma+postgres:// — the card rejects them and says which string to generate
Saved as
PostgreSQL, with Prisma kept as a badge — there is no connection type called Prisma
Default schema
public, which is what a federated reference carries

The Accelerate rejection is the most valuable thing this card does. Accelerate is Prisma's connection pooler and edge cache, and for an application it is usually the right thing to use — which is why the console offers it prominently. It is simply not a Postgres endpoint, so a tool connecting with a Postgres driver cannot speak to it. Without a specific message, pasting one produces a failure that reads like bad credentials and sends people to regenerate a password that was fine.

The shared hostname deserves a moment's thought about credentials. On a service where your database sits at a long unguessable hostname, that address is a weak second factor — not security, but friction. Prisma removes it by design: db.prisma.io is the same for everybody, so the generated username and password are doing all the work. Scope the user to read-only and treat the string as you would any other secret.

For a cross-source query Prisma is ordinary Postgres. A connection you called prisma_app is written prisma_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: www.prisma.io

FAQ

Questions about Prisma Postgres

Which tools can read Prisma Postgres 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 Prisma Postgres 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 Prisma Postgres?

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 Prisma Postgres?

A reachable host, a role and its password — the agent carries the driver, so nothing is installed on the database. Host: db.prisma.io — the same for every Prisma Postgres database. Port: 5432. Driver: Npgsql, carried by the agent — nothing to install at the Prisma end. Paste format: The direct TCP string from the Prisma Console, as a postgres:// URI.

Can I join Prisma Postgres to another database in the same query?

Yes — that is a federated query. One statement can reference Prisma Postgres 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 Prisma Postgres different from connecting PostgreSQL?

Only the connection string. Prisma Postgres speaks the PostgreSQL wire protocol, so filters, scheduling, sharing, the Excel and Google Sheets add-ons and the MCP server all behave identically. The Prisma card pre-fills the host, port and SSL settings that provider expects.

Is there a Prisma to Excel guide?

Yes — it is the PostgreSQL guide, and it is correct for Prisma Postgres as written. Prisma speaks the PostgreSQL wire protocol, so Prisma to Excel, Prisma to Google Sheets and every other destination follow the same steps. The only Prisma-specific part is the connection string, and the Prisma card fills that in for you.

Put Prisma 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