Prisma P1001: Can't reach database server at localhost:5432

P1001 means Prisma opened no connection at all. It never got as far as your password or your database name. The trouble is that it prints exactly the same sentence whatever the reason. I triggered it five different ways, and the message only ever changed in the host and port:

Step 1: find out which one you have

node -e "const s=require('net').connect(5432,'localhost');s.setTimeout(5000);s.on('connect',()=>{console.log('open: something is listening');s.destroy()}).on('timeout',()=>{console.log('timeout: no answer at all');s.destroy()}).on('error',e=>console.log(e.code))"

Run it from the same place your app runs: inside the container if the app is in a container. Otherwise you’re testing a different network.

Nothing is listening on that port

With my Postgres container stopped, and separately with the right server but the default port 5432 (mine was mapped to 55432), Prisma gave the P1001 above in both cases. The quick check said ECONNREFUSED.

$ docker ps --format "{{.Names}} {{.Ports}}"
nk-pg 0.0.0.0:55432->5432/tcp

DATABASE_URL="postgresql://postgres:password@localhost:55432/postgres"

Docker: localhost and service names

Most P1001 reports involve Docker, because “localhost” means a different machine depending on where the code runs. I ran Prisma inside a node:24-alpine container on the same Docker network as Postgres (service name postgres, container port 5432, mapped to 55432 on the host):

And the reverse mistake: running npx prisma migrate on your machine with the URL from your Compose file. postgres only exists inside Docker’s network, so from Windows I got P1001: Can't reach database server at `postgres:5432` (the quick check said ENOTFOUND).

# app running in a container on the same Compose network
DATABASE_URL="postgresql://postgres:password@postgres:5432/postgres"

# prisma CLI running on your machine
DATABASE_URL="postgresql://postgres:password@localhost:55432/postgres"

No answer at all: firewalls, IPs and Supabase

When nothing answers at all, the quick check prints timeout. Prisma 6’s CLI failed about as fast as it did for a closed port, but a Prisma 7 app waited about 30 seconds first (see the Prisma 7 table below). Usually it’s a firewall or security group not allowing your IP, a VPN, or simply the wrong IP.

For hosted Supabase there’s a common version of this that I couldn’t reproduce here (it needs a hosted project). Per Supabase’s connection docs, the direct host db.<project>.supabase.co is IPv6 unless you pay for the IPv4 add-on. On an IPv4-only network (many home ISPs, some CI runners and hosts) it can’t be reached at all.

Once Prisma connects, Supabase’s API can still refuse your writes with a different code. That one is Supabase error 42501.

Something is listening, but it isn’t Postgres

The local Supabase stack runs the database on 54322 and its HTTP API on 54321. Pointing Prisma at 54321 didn’t give a protocol error. It gave the same P1001, even though the port was open and answering:

Error: P1001: Can't reach database server at `127.0.0.1:54321`

Port 54322 worked. If the quick check says open but Prisma says P1001, compare your port with what’s actually serving Postgres.

Prisma 7 doesn’t always say P1001

In Prisma 7, the CLI (prisma migrate dev) still prints P1001. But in your app, which talks to the database through a driver adapter such as @prisma/adapter-pg, the same problems produced three different errors:

So if you only grep logs for P1001 on Prisma 7, you’ll miss the stopped database entirely. Prisma 6’s client, for comparison, threw PrismaClientInitializationError with the same “Can’t reach database server” text as the CLI.

What didn’t work

How this was tested

Postgres 17 in Docker Desktop 4.94.0 on Windows 11, mapped to port 55432, with Prisma 6.19.3 (prisma db push and a client query) and Prisma 7.10.0 (prisma migrate dev, plus queries through @prisma/adapter-pg). Each failure was produced on purpose: container stopped, wrong port, Compose host name used from Windows, a non-routable IP (10.255.255.1), and the API port of a local Supabase stack (CLI 2.120.0). The container cases ran in node:24-alpine on a user-defined Docker network with Postgres aliased as postgres. Hosted Supabase (IPv6, poolers) wasn’t tested: those notes come from Supabase’s documentation, linked above.

The code for every case above is public, so you can run it yourself: prisma6-noinit and prisma-init in nk-repro.