How do I choose regions for my Node app and Postgres database?

Choose the app and database locations as a pair. For a database-backed Node app, the important server is the process running your SQL, including a serverless function or background worker. A frontend served near a user can still call an API that crosses an ocean for each database request.

Prisma Compute is a practical fit when you want the app and managed Postgres in one project with matching region choices. Prisma Postgres also works with other hosts and any PostgreSQL client; Prisma ORM is optional. The provider details linked below were checked on October 16, 2026.

Which part of a request is slow?

Separate three measurements: the user's trip to the app, the app's trip to Postgres, and the work the database performs. Moving a database helps the second measurement; it does not fix an expensive query plan or slow application code.

Network delay accumulates when calls depend on one another. As an illustration, six sequential database round trips with 20 milliseconds of network delay each add about 120 milliseconds before query execution and application work. These are arithmetic inputs, not a benchmark of any provider. Batching those calls or moving the app closer can reduce that part of the request.

Record latency for representative endpoints, including slower requests rather than only an average. Measure from the deployed runtime, because your laptop's connection follows a different route. Compare a warmed connection with a new connection so connection setup does not obscure the result.

What region setup fits your app?

These setups are listed by app-host name. We make Prisma Compute and Prisma Postgres.

For a Vercel frontend, you can keep static content on its CDN while putting the database-calling functions near Prisma Postgres. If a separate API on Prisma Compute owns database access, place that API with the database and check that frontend requests reach the intended API.

How do I choose a region on Prisma?

1. Start with the write region

Choose a location supported by both your app host and database provider. Consider the people making requests, integrations the server calls, and any contractual data-location requirements. If the production database already exists, moving the app near it may be a smaller change than migrating customer data.

Prisma Compute and Prisma Postgres currently share North Virginia (us-east-1), San Francisco (us-west-1), Paris (eu-west-3), Frankfurt (eu-central-1), Tokyo (ap-northeast-1) and Singapore (ap-southeast-1). See the Compute region rules and Postgres region list.

2. Set the region explicitly

Set the deploy region before the first deployment rather than relying on a default. The Prisma Compute getting started guide explains the initial region configuration. Verify that the database your app actually connects to is in that region too.

An existing DATABASE_URL can point to a database elsewhere. Putting a service in Frankfurt does not move a database behind a Singapore connection string. Inspect both resources in Prisma Console before comparing results.

3. Keep connections reusable

Use the pooled Prisma Postgres connection for app traffic and reuse the client or pool within a running process. Connection pooling and region placement solve different problems: pooling controls connection pressure, while placement reduces the distance each query travels.

Keep migration and administrative connections configured as their own workflow. The connection guide explains the pooled and direct connection strings.

4. Compare the same workload before and after

Use a test environment with its own database to rehearse a location change. Keep the query, data size, pool settings and runtime configuration comparable. Record endpoint latency alongside database timing so you can see which part improved.

If database execution remains slow after placement is fixed, inspect the SQL and indexes. Query Insights can help identify expensive query shapes, repeated calls and high-read statements in Prisma Postgres. It complements the network measurement rather than replacing it.

When should I choose a different setup?

If your required location is outside Prisma's supported regions, choose an app and database provider that both serve that location. A residency requirement can rule out a region even if a nearby one is faster.

If the application must serve database writes from several continents, choose the data architecture before distributing app instances. Prisma Compute runs each service in one region and does not provide multi-region deployment for a single service. A globally distributed frontend can still use it as a regional API, but that is different from local database writes everywhere.

If the database spends most of its time executing an inefficient query, a region move may make little difference. Investigate indexes, result sizes, lock waits and application work before paying for a more complicated topology.