Skip to content

Diagnosing Prisma P1001 (can't reach database server)

Covers confirming basic network reachability to the named host:port and the usual reasons it's blocked. Does not cover a missing or malformed connection string (see the PrismaClientInitializationError playbook) — by the time you have a specific host:port in the error, the string was parsed successfully.

Prisma
Unverifiedno reproductions yetWhy this confidence?
Revision 1published by DevYou curationrevision history
Run the diagnosisEvidence and compatibility

Symptoms

The diagnostic path

7 steps. Every step is written out below in full — the interactive version simply follows the branches for you.

  1. Step 1 · StartP1001: can't reach database server at a specific host:port

    The string parsed fine — Prisma is telling you exactly which host and port it tried and failed to reach.

    What happens next

    • passed → step 2, Can you reach that exact host and port from the same environment?

  2. Step 2 · TestCan you reach that exact host and port from the same environment?

    Run from inside the deploy environment, not from your local machine.

    Read-onlybash
    nc -zv db.internal 5432

    Expected result

    Connection to db.internal 5432 port [tcp/postgresql] succeeded!

    What happens next

    • passed → step 3, Network path is open — Postgres itself is refusing or dropping it
    • failed → step 4, The network path itself is blocked or misconfigured
    • unknown → step 4, The network path itself is blocked or misconfigured

  3. Step 3 · Root causeNetwork path is open — Postgres itself is refusing or dropping it

    Check that Postgres is actually running and listening on that interface (listenaddresses), that pghba.conf allows this client's address/user/database combination, and that the port matches — managed providers sometimes use a different port for a pooled connection than a direct one (e.g. Supabase's pooler on 6543 vs 5432 direct).

    What happens next

    • passed → step 5, Fix reachability at its actual layer

  4. Step 4 · Root causeThe network path itself is blocked or misconfigured

    For a managed/cloud database this is most often: the deploy environment's egress IPs aren't allow-listed by the database's firewall/security group, the hostname is a private/internal DNS name that only resolves inside a VPC while this deploy runs outside it (e.g. serverless or edge), or the database is paused/down.

    What happens next

    • passed → step 5, Fix reachability at its actual layer

  5. Step 5 · FixFix reachability at its actual layer

    Depending on which of the above applies: allow-list the deploy environment's egress IPs in the database's firewall/security group; if the host is private-DNS-only, connect through whatever the provider requires for external access (a public endpoint, a proxy such as Cloudflare Hyperdrive or PgBouncer, or VPN/peering); or if Postgres itself is down, restart it and re-check pg_hba.conf. There's no single universal command — the blockage differs per environment.

    What happens next

    • passed → step 6, Retry the same reachability check

  6. Step 6 · Verify the fixRetry the same reachability check

    Confirm the port opens now.

    Read-onlybash
    nc -zv db.internal 5432

    Expected result

    Connection to db.internal 5432 port [tcp/postgresql] succeeded!

    What happens next

    • passed → step 7, Resolved
    • failed → step 4, The network path itself is blocked or misconfigured
    • unknown → step 4, The network path itself is blocked or misconfigured

  7. Step 7 · EndResolved

    The port is reachable and Prisma can now initialize its connection.

Sources

Why this confidence?

What would strengthen it: 6 more independent reproductions. Reproductions from 3 more distinct environments.