# How a Prisma Compute app reaches Prisma Postgres: same-region networking, resume time and the planned internal network

URL: https://www.prisma.io/blog/prisma-compute-postgres-same-region-networking
Published: 2026-11-10
Authors: Gregory Boch
Tags: platform, prisma-postgres
Description: How a Prisma Compute app connects to Prisma Postgres in the same region today, what sleeping does to the connection, and the planned internal network.

> Blog posts describe Prisma as it was on the date shown and are not kept current. Before implementing from a post, check the documentation index at https://www.prisma.io/docs/llms.txt and the changelog at https://www.prisma.io/changelog.md.

> For an index of every published post, fetch https://www.prisma.io/blog/llms.txt.

A Prisma Compute app reaches its Prisma Postgres database over TLS, through the database's public endpoint, and you put both in the same region. The app and the database run in one project, each in a region you choose from the same six, and the app gets its connection string from the project: Prisma Composer passes it in at runtime, or the app reads an environment variable such as `DATABASE_URL`. We make Prisma Compute and Prisma Postgres. This post covers the connection path today, what happens to it when an idle app sleeps, the internal network we plan to add, and how Railway, Render, Fly.io and Neon connect an app to its database.

## Today: one endpoint, in the same region [#today-one-endpoint-in-the-same-region]

Every Prisma Postgres database has two [connection strings](https://www.prisma.io/docs/postgres/database/connecting-to-your-database):

| String | Host                       | Use it for                                    |
| ------ | -------------------------- | --------------------------------------------- |
| Pooled | `pooled.db.prisma.io:5432` | Application queries                           |
| Direct | `db.prisma.io:5432`        | Migrations, `pg_dump`, `psql` and admin tools |

Both use `sslmode=require`: TLS is mandatory. A Compute app connects through these public endpoints too, so its traffic to the database goes through the public entry point, not a private network.

What this means in practice:

* **Anyone holding a connection string can connect from the internet.** The string carries the password, and every credential has full access to its database. Keep it in the project's environment, never in the repository. If it leaks, [create a new credential, switch the app to it and delete the old one](https://www.prisma.io/docs/postgres/database/connecting-to-your-database#rotate-or-delete-a-credential). Rotating the credential isn't enough on its own, because after a rotate the old password can keep working, and sessions opened before the delete may keep running; the linked steps say when to contact support.
* **Region is what you control.** Every query travels from the app to the database's region and back. Compute services and Prisma Postgres share six regions (`us-east-1`, `us-west-1`, `eu-west-3`, `eu-central-1`, `ap-northeast-1`, `ap-southeast-1`), so put both in the same one. A database's region can't be changed after you create it.

## What sleeping does to the connection [#what-sleeping-does-to-the-connection]

By default, Compute [scales idle instances to zero](https://www.prisma.io/docs/compute/keeping-instances-awake): an idle instance sleeps with a memory snapshot and resumes with its memory intact.

* **Resume time.** We measured a median resume of about 30 to 40 ms for a sleeping instance. That's the instance waking up, not time to first byte: your handler's own work comes on top, and we haven't published a time-to-first-byte figure.
* **Pooled connections close after 60 idle minutes.** Apps use the pooled string, and the pooler closes pooled connections that sit idle for 60 minutes ([connection pooling](https://www.prisma.io/docs/postgres/database/connection-pooling)), so an instance that slept longer than that can wake to a closed connection. A connection that is still open survives the sleep itself, unless the instance slept for more than about three days. Either way, use a pool or client that reconnects after a failed connection rather than holding one connection forever.
* **Bounded work that outlives a request** can keep the instance awake with [`waitUntil` or `KeepAwakeGuard`](https://www.prisma.io/docs/compute/keeping-instances-awake), so the instance doesn't sleep in the middle of it. Both are best-effort: they don't carry work through a restart or a deploy.

## Planned: an internal network per project [#planned-an-internal-network-per-project]

We plan to put each project's apps and Postgres databases on an internal network in their region, the setup other hosts often call a VPC:

* All apps and databases in a project would run in one region and talk to each other over the internal network.
* Prisma Composer would declare which app can reach which database, and which apps and databases are reachable from the internet.
* A common setup would be: the web app is public, it talks to Postgres over the internal network, and Postgres can't be reached from the internet at all.

There's no date for it yet. Until it ships, the connection path is the one described above. We'll update this post when it does.

## How other hosts connect an app to its database [#how-other-hosts-connect-an-app-to-its-database]

Rows are in alphabetical order, and each row was checked on 2026-11-10 against the vendor's own docs.

| Host                             | App-to-database path                                                                                                                                                     | Source                                                                                                                                                                |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Fly.io                           | Apps in an organization share a private WireGuard mesh (6PN) with `.internal` DNS, on by default. A Managed Postgres cluster sits in the organization's private network. | [Private networking](https://docs.fly.io/networking/private-networking), [Managed Postgres](https://docs.fly.io/postgres)                                             |
| Neon                             | By default, apps connect over the open internet through the Neon proxy. Private Networking (AWS PrivateLink) and IP Allow are on the Scale plan.                         | [Private Networking](https://neon.com/docs/guides/neon-private-networking), [IP Allow](https://neon.com/docs/introduction/ip-allow)                                   |
| Prisma Compute + Prisma Postgres | Over TLS through the database's public endpoint; create both in the same region. An internal network per project is planned, with no date yet.                           | [Connection strings](https://www.prisma.io/docs/postgres/database/connecting-to-your-database), [Compute limitations](https://www.prisma.io/docs/compute/limitations) |
| Railway                          | Services in a project talk over encrypted WireGuard tunnels with internal DNS, without exposing traffic to the public internet. Each environment has its own network.    | [Private networking](https://docs.railway.com/networking/private-networking)                                                                                          |
| Render                           | Apps should use the database's internal URL, which needs the service and the database in the same account and region.                                                    | [Creating and connecting](https://render.com/docs/postgresql-creating-connecting)                                                                                     |

If you're comparing Neon with a host that runs the app and the database together, the default path is the same for Neon and Prisma Postgres: a connection to the database's public endpoint. Fly.io and Railway put the app and the database on a private network, and Render does when the app uses the internal URL.

## Checklist for today [#checklist-for-today]

* Create the Compute service and the database in the same region.
* Use the pooled string for app queries and the direct string for migrations and admin tools.
* Keep connection strings in the project's environment, and replace a leaked one as described above.
* Use a pool or client that reconnects after a failed connection.

## Sources [#sources]

Checked 2026-11-10:

* Prisma: [connection strings, credentials and regions](https://www.prisma.io/docs/postgres/database/connecting-to-your-database), [connection pooling](https://www.prisma.io/docs/postgres/database/connection-pooling), [Prisma Postgres regions](https://www.prisma.io/docs/postgres/faq#what-regions-is-prisma-postgres-available-in), [keeping instances awake](https://www.prisma.io/docs/compute/keeping-instances-awake), [Compute limitations](https://www.prisma.io/docs/compute/limitations), [Compute FAQ](https://www.prisma.io/docs/compute/faq). The resume time and the three-day connection limit come from the Prisma Compute team.
* Fly.io: [private networking](https://docs.fly.io/networking/private-networking), [Managed Postgres](https://docs.fly.io/postgres).
* Neon: [Private Networking](https://neon.com/docs/guides/neon-private-networking), [IP Allow](https://neon.com/docs/introduction/ip-allow).
* Railway: [private networking](https://docs.railway.com/networking/private-networking).
* Render: [creating and connecting to Render Postgres](https://render.com/docs/postgresql-creating-connecting).

## Update history [#update-history]

* 2026-11-10: first published.