Prisma P1001 on Neon: Can't reach database server

By Ohad Krispin, founder of VibeRaven · LinkedIn

"Can't reach database server at ep-...neon.tech:5432" is Prisma error P1001. On Neon it most likely means Prisma Client's connection timed out before the compute woke up: Neon suspends a compute after 5 minutes without activity, and on the Free plan that setting is fixed. Add connect_timeout=15 to the connection string (Prisma's default is 5 seconds), retry the first query, and redeploy. The same message appears for a wrong host or port, so compare the string with the Neon Connect dialog first. Reproduced with prisma 6.19.3 on 2026-10-31, the message only, against a closed local port.

What connect_timeout should I use for Neon with Prisma?

Prisma's Neon page defines connect_timeout as the maximum number of seconds to wait for a new connection to be opened, with a default of 5 and 0 meaning no timeout. Prisma's own pool has a separate default timeout of 10 seconds, raised with pool_timeout. Neon's examples use 15 for both. Neon also warns that longer timeouts make users wait longer when a cold start does happen, so test the value and watch it.

DATABASE_URL="postgresql://USER:PASSWORD@ep-example-123456-pooler.us-east-2.aws.neon.tech/dbname?sslmode=require&connect_timeout=15&pool_timeout=15"

Why does my Neon database fail after the app has been idle?

Neon scales a compute to zero after 5 minutes of inactivity. Waking it typically takes a few hundred milliseconds, and Prisma's page says it can take longer if the project was idle for more than 7 days. A connection opened before the suspend breaks too: Neon lists "Terminating connection due to administrator command" as the error when an old connection is used after the compute suspended, and says to reconnect before querying or to turn scale to zero off on a paid plan. Neon's example for node-postgres sets connectionTimeoutMillis to 10000.

import { Pool } from "pg";

export const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
  connectionTimeoutMillis: 10000,
});

How do I tell a Neon cold start from a wrong connection string?

P1001 is the same text for both. Prisma builds it for any unreachable server (libs/user-facing-errors/src/common.rs) and wraps the host and port in backticks. A run of prisma 6.19.3 against a closed local port printed the same P1001 text with that host and port, with no Neon involved. Neon lists a wrong string as a different error, "Password authentication failed for user", and a proxy that could not reach a restarting compute as "Couldn't connect to compute node", where it says to retry. So read the host in the message, compare it with the Connect dialog, and only then change timeouts.

Checklist

How to fix it, then check the fix

01Read the host in the error and compare it with the connection string from the Neon Connect dialog. A different host or a typo is not a cold start.
02
Add connect_timeout to the DATABASE_URL in Vercel for Production and Preview:
```
...neon.tech/dbname?sslmode=require&connect_timeout=15
```
03If the app uses pg or another TCP driver, set that driver's own connect timeout, for example connectionTimeoutMillis: 10000, and retry the first query with backoff. Neon's example retries 5 times with a minimum wait of 4000 ms and randomization.
04Redeploy. Vercel applies a changed variable only to new deployments.
05Check the fix: leave the app idle for more than 5 minutes, load a page that queries the database, and confirm the first request succeeds in the function logs. On a paid plan you can turn scale to zero off instead.

Sources

Official docs behind this checklist

More provider errors

Browse all launch guides · Read resources · How to make and check your next change

FAQ

FAQ for builders before launch

How long does a Neon compute take to wake up?

Neon says activation typically takes a few hundred milliseconds. Prisma's Neon page adds that it can take longer if the project has been idle for more than 7 days.

Can I stop Neon from suspending my compute?

On a paid plan, yes: Neon says you can turn scale to zero off. On the Free plan the setting is fixed. Neon also says a compute that never suspends has to be restarted by hand to pick up compute image updates.

Does the same fix apply to pg or Drizzle?

The idea does. Neon recommends a longer connection timeout in every driver, such as connectionTimeoutMillis: 10000 for pg, plus retries with exponential backoff. Prisma takes its timeout as a URL parameter; Neon lists the equivalents for other drivers, such as connect_timeout=10 for psycopg2.