Error: P1001: Can't reach database server

[Tembogs]

Question

C:\Users\mosho\PJC\backend\contact-support>npx prisma db push
[dotenv@17.2.4] injecting env (6) from .env -- tip: 🛠️ run anywhere with dotenvx run -- yourcommand
Loaded Prisma config from prisma.config.ts.

Prisma schema loaded from prisma\schema.prisma.
Datasource "db": PostgreSQL database "postgres", schema "public" at "aws-0-eu-west-1.pooler.supabase.com:5432"

Error: P1001: Can't reach database server at aws-0-eu-west-1.pooler.supabase.com:5432

Please make sure your database server is running at aws-0-eu-west-1.pooler.supabase.com:5432. im trying to connect my prisma to my supabase database but keep hitting the error above

How to reproduce (optional)

Expected behavior (optional)

No response

Information about Prisma Schema, Client Queries and Environment (optional)

// Add your schema.prisma

generator client {
provider = "prisma-client-js"
}

datasource db {
provider = "postgresql"

}

import { PrismaClient } from "@prisma/client";
import { PrismaPg } from "@prisma/adapter-pg";


if (
  process.env.NODE_ENV === "test" &&
  process.env.DATABASE_URL?.includes("render.com")
) {
  throw new Error("🚨 TEST ENV CONNECTING TO PROD DB — ABORTED");
}

const url = process.env.DATABASE_URL!;

if (process.env.NODE_ENV === "test" && !url.includes("contact_support_test")) {
  throw new Error("🚨 DATABASE_URL is not test database!");
}

const adapter = new PrismaPg({
  connectionString: url,
});


const globalForPrisma = globalThis as unknown as { prisma?: PrismaClient };

export const prisma =
  globalForPrisma.prisma ??
  new PrismaClient({
    adapter,
  });

if (process.env.NODE_ENV !== "production") {
  globalForPrisma.prisma = prisma;
}

export default prisma;

// Add any relevant Prisma Client queries here

• OS: Windows

• Database: PostgreSQL

• Node.js version: v24.13.0

• Run prisma -v to see your Prisma version and paste it

• prisma : 7.6.0
  @prisma/client : 7.6.0
  Operating System : win32
  Architecture : x64
  Node.js : v24.13.0
  TypeScript : 5.9.3
  Query Compiler : enabled
  PSL : @prisma/prisma-schema-wasm 7.6.0-1.75cbdc1eb7150937890ad5465d861175c6624711
  Schema Engine : schema-engine-cli 75cbdc1eb7150937890ad5465d861175c6624711 (at node_modules@prisma\engines\schema-engine-windows.exe)
  Default Engines Hash : 75cbdc1eb7150937890ad5465d861175c6624711
  Studio : 0.27.3

[nurul3101]

Hey @Tembogs!

Can you please try using the direct connection string and check if it works for you? Use the non pooled connection string (without the pooler) for running migrate dev or db push commands.

[github-actions[bot]]

Hi,

As we have not heard back from you, we are closing this discussion to keep our discussions organized.

Feel free to start a new discussion if this remains relevant.

Thank you for being part of the community!

[JosephHampton]

A P1001 against a Supabase pooler host is almost always one of these, in order of how often I've seen it:

1. Wrong port for what you're doing. Supabase hands you two connection strings and db push / migrate need the right one:

• Pooler in transaction mode is port 6543 (add ?pgbouncer=true), and that's for your app's runtime queries. This port does not support the schema and DDL work prisma db push and prisma migrate need.
• Direct / session connection is port 5432, and that's what migrations and db push want.

So point Prisma's migration URL at the direct connection, not the transaction pooler:

datasource db {
  provider  = "postgresql"
  url       = env("DATABASE_URL")   // pooler 6543 ?pgbouncer=true, runtime queries
  directUrl = env("DIRECT_URL")     // direct 5432, used by migrate / db push
}

2. IPv6 vs IPv4. Supabase's direct connection resolves to IPv6 by default. If your network is IPv4 only (a lot of home ISPs, some CI runners) the TCP connection just silently fails and you get P1001. Fix is either the Session pooler string (that one is IPv4 friendly) or turning on Supabase's IPv4 add on.

3. Project is paused. Free tier projects pause after inactivity and refuse connections until you resume them in the dashboard. Quick thing to rule out.

For your case (a db push to a :5432 pooler host failing) I'd start with #2, swap to the Session pooler connection string, since it's IPv4 friendly and still supports migrations. That clears most of these.

If that gets you connected, marking it as the answer would help the next person who googles P1001.