Prisma 7.10.1 Schema Engine returns P1001 on Windows, but PostgreSQL driver connects successfully

[RRINNOVATION]

Prisma 7.10.1 Schema Engine returns P1001 on Windows, but PostgreSQL driver connects successfully

Hello Prisma team,

I'm troubleshooting a connection issue between Prisma ORM and a fresh Neon PostgreSQL database. I need help identifying why Prisma's native Schema Engine cannot connect when the PostgreSQL driver and Prisma adapter can connect successfully.

Environment

• OS: Windows 64-bit
• Node.js: 24.18.0
• Prisma CLI: 7.10.1
• Prisma Client: 7.10.1
• @prisma/adapter-pg: 7.10.1
• pg: 8.23.1
• Database: Neon PostgreSQL
• Database schema: public, currently empty

What works

1. Direct PostgreSQL connection using the Node.js pg driver.
2. Pooled PostgreSQL connection using pg.
3. Prisma PostgreSQL adapter connection using @prisma/adapter-pg, including a successful SELECT current_database() query.
4. npx prisma validate.
5. DNS resolution and TCP connectivity to port 5432.

What fails

Both commands return P1001:

npx prisma migrate status
npx prisma db pull

The failure persists with both direct and pooled Neon endpoints, after trying a longer connection timeout, removing channel_binding=require, changing SSL mode, preferring IPv4, and upgrading Prisma packages from 7.10.0 to 7.10.1.

Prisma 7 configuration

prisma.config.ts:

import "dotenv/config";
import { defineConfig, env } from "prisma/config";

export default defineConfig({
  schema: "prisma/schema.prisma",
  migrations: {
    path: "prisma/migrations",
    seed: "tsx prisma/seed/catalog.ts",
  },
  datasource: {
    url: env("DATABASE_URL_UNPOOLED"),
  },
});

prisma/schema.prisma:

datasource db {
  provider = "postgresql"
}

The Schema Engine executable starts and reports its version correctly. No migrations have been applied to the fresh database.

Questions

1. Why might the native Schema Engine return P1001 when pg and @prisma/adapter-pg connect successfully from the same Windows machine?
2. Are there known Windows, DNS, TLS, IPv6, or connection-string parsing issues in Prisma 7.10.1 that could explain this behavior?
3. What specific diagnostic command or log can reveal the underlying connection error from the Schema Engine without exposing database credentials?
4. Is there a supported workaround to apply Prisma migrations safely while this issue is investigated?

I want to use Prisma's existing migration history to initialize the fresh database without modifying production data.

Thank you.

[praveen-kumary]

The reason you're seeing this discrepancy comes down to Prisma 7's architecture: runtime queries and CLI schema operations use two completely different networking and TLS stacks under the hood.

---

1. Why @prisma/adapter-pg connects but the Schema Engine fails with P1001

• @prisma/adapter-pg runs inside the Node.js runtime and delegates connection and TLS management to pg (node-postgres), which relies on Node's bundled OpenSSL and Mozilla root certificates.
• prisma migrate and prisma db pull do not use the JavaScript driver adapter. They spawn the native compiled Rust binary (schema-engine).
• On Windows, the Rust schema-engine establishes its own independent TCP socket and TLS handshake using the Windows CryptoAPI/Schannel store. Because Neon endpoints (ep-...aws.neon.tech) strictly require Server Name Indication (SNI) and TLS negotiation:
  1. Windows Root CA On-Demand Loading: Windows often does not pre-populate intermediate or cross-signed Let's Encrypt certificates in the machine/user certificate store until a native Windows component (like Edge/WinINet) triggers it.
  2. Winsock IPv6 Preference (AAAA): On Windows, dual-stack DNS returns IPv6 records first. If your local ISP, router, or VPN lacks a functional IPv6 route to Neon's AWS region, the Windows socket hangs on SYN packets until timing out (P1001), whereas Node's dns module falls back to IPv4 via Happy Eyeballs.
  3. Neon Serverless Cold Starts: Neon compute instances scale to zero when idle. The Rust schema-engine defaults to a tight socket timeout (~5s) unless explicitly told to wait.

---

2. Known Windows & Connection String Considerations

• Connection parameters: Ensure your DATABASE_URL_UNPOOLED string has sslmode=require and an explicit timeout:

  DATABASE_URL_UNPOOLED="postgresql://user:password@ep-your-instance.us-east-2.aws.neon.tech/neondb?sslmode=require&connect_timeout=30"

• Special Characters in Passwords: If your database password contains characters like #, @, or %, URL-encode them. Rust URL parsers are stricter than pg and can inadvertently truncate the host or port.

---

3. Diagnostic Commands to Reveal Underlying Socket Errors

To see the exact Rust socket/TLS failure without exposing credentials, run in PowerShell:

$env:DEBUG="prisma:*"
$env:RUST_LOG="schema_engine=trace,quaint=trace"
$env:RUST_BACKTRACE="1"
npx prisma migrate status

Prisma will automatically mask your password (postgresql://user:*****@...), but the trace logs will print the exact underlying OS error code (e.g., WSAETIMEDOUT 10060, WSAENETUNREACH 10051, or CertVerifyFailed).

---

4. Workarounds to Apply Migrations Safely

If you need to initialize or apply migrations right now while investigating the Windows socket issue:

1. Run via WSL2 (Recommended):
   Open the repository in WSL2 (Ubuntu) and run npx prisma migrate status / npx prisma migrate deploy. Linux engine builds use statically linked OpenSSL and standard Linux socket resolution, bypassing Windows Winsock/Schannel entirely.
2. Generate SQL Script via prisma migrate diff:
   You can generate the migration SQL locally without any active database connection:

   npx prisma migrate diff --from-migrations ./prisma/migrations --to-schema-datamodel ./prisma/schema.prisma --script > migration.sql

   Execute migration.sql through your working @prisma/adapter-pg script or the Neon SQL Editor, then mark it resolved:

   npx prisma migrate resolve --applied <migration_directory_name>

[RagedPanda]

The error code narrows this down quite a bit. In Prisma 7.10.1, migrate status and db pull always go through the native schema-engine binary (Migrate.setup() only creates SchemaEngineCLI), and prisma.config.ts has no option to route them through @prisma/adapter-pg. So that binary has to reach Neon by itself, using its own stack: tokio-postgres with native-tls, which is SChannel and the Windows certificate store on Windows.

What P1001 does and doesn't mean

In the engine's error mapping (quaint postgres/native/error.rs, user-facing-errors quaint.rs):

• a socket-level I/O error while connecting → ConnectionError → P1001
• the connect timing out (default connect_timeout is 5 seconds) → ConnectTimeout → P1001
• a TLS handshake or certificate failure (native_tls::Error) → TlsError → P1011 ("Error opening a TLS connection")
• wrong password or a missing database → P1000 / P1003

So a certificate-store problem would normally show up as P1011, not P1001. P1001 means the binary either couldn't open the TCP connection or didn't finish connecting within the timeout.

Things to check, given that node.exe gets through from the same machine

1. Look at the host in the full message. P1001 prints Can't reach database server at host:port. Make sure that's the Neon host you expect: it confirms DATABASE_URL_UNPOOLED is what the CLI actually loaded through prisma.config.ts.
2. The timeout. Add connect_timeout=30 to the URL query string. The engine reads it from there (0 disables the timeout). A timeout passed any other way doesn't reach the binary.
3. Per-program firewall or antivirus rules. Windows Firewall, endpoint security or a VPN client can allow node.exe but block a different, unsigned executable from making outbound connections. That gives exactly this pattern, and it surfaces as an I/O error, so P1001. The binary is schema-engine-windows.exe under node_modules/@prisma/engines/. Try allowing it, or temporarily turn off the security software, and run prisma migrate status again.
4. IPv6. If the host resolves to an IPv6 address your network can't route, the native client may spend its whole timeout on it. Raising connect_timeout helps tell this apart from a hard block.

Seeing the underlying error without leaking credentials

The CLI pipes the engine's stderr into the prisma:schemaEngine:stderr debug namespace, and passes through your own RUST_LOG (it only defaults it to info). In PowerShell:

$env:DEBUG = "prisma:schemaEngine:stderr"
$env:RUST_LOG = "debug"
npx prisma migrate status

Using that one namespace instead of prisma:* keeps out the RPC/stdin traffic. Still look over the output before you share it, and redact the host if you need to.

Applying your migrations in the meantime

migrate deploy applies the existing history to an empty database and records it in _prisma_migrations. It needs the same engine connection, so the reliable workaround is to run it from an environment where that connection works: WSL (Linux engine binary and a different network path), a CI job, or another machine. For example:

DATABASE_URL_UNPOOLED="postgresql://...?sslmode=require&connect_timeout=30" npx prisma migrate deploy

I'd avoid running the migration.sql files by hand with pg/psql. That leaves _prisma_migrations empty, and you'd need prisma migrate resolve --applied, which also needs the engine connection.