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.

[praveen-kumary]

The reason this happens is due to the difference between how Node.js handles TLS/DNS vs. how Prisma's native Rust Schema Engine handles them on Windows:

---

1. Why pg / @prisma/adapter-pg works, but Schema Engine returns P1001

• Node.js runtime (@prisma/adapter-pg and pg): Uses Node's built-in JavaScript/C++ network stack, which ships with Mozilla's pre-compiled CA certificate bundle and Node's DNS resolver.
• Prisma CLI (prisma migrate status, db pull): Does not use @prisma/adapter-pg. Instead, the CLI spawns the native Rust binary (schema-engine-windows.exe), which connects using Rust's tokio-postgres and the Windows system certificate store (rustls-native-certs / Schannel).

When connecting to Neon (*.neon.tech) from Windows, two common discrepancies cause P1001 in Rust while succeeding in Node:

1. Server Name Indication (SNI) & TLS Handshake: Neon multiplexes connections based on the SNI hostname (ep-xyz-123456.region.neon.tech). If the connection string lacks an explicit sslmode=require, or if a Windows firewall/VPN/proxy intercepts the TLS handshake, Node's pg driver may tolerate it while Rust's strict TLS verification rejects the socket before sending the startup packet.
2. Windows Certificate Store vs. Let's Encrypt / ISRG Root: The Rust engine queries the Windows user/machine certificate store. If the ISRG Root X1 or intermediate CA certificate is missing or not synced in the Windows trust store, the Rust TLS handshake fails immediately with a socket disconnect, which Prisma surfaces as P1001 (Cannot reach database server).

---

2. How to reveal the exact underlying Rust error (Safe Diagnostics)

Run the command with the RUST_LOG environment variable enabled. This forces the native Schema Engine to print its exact socket and TLS error before returning P1001, without printing your credentials:

In PowerShell:

$env:RUST_LOG="debug,quaint=trace"
$env:DEBUG="prisma:schema-engine*"
npx prisma migrate status --config=prisma.stage10.config.ts

In the output, look specifically for lines like:

• tls: certificate verify failed: UnknownIssuer (Missing root CA in Windows store)
• tls: invalid peer name (SNI mismatch)
• connection reset by peer / timeout (Port 5432 routing / MTU issue)

---

3. Immediate Fixes to Try

A. Explicit SSL & Connect Timeout Parameters

Ensure your Neon unpooled connection string explicitly specifies:

postgresql://user:password@ep-xyz-123456.us-east-2.aws.neon.tech/neondb?sslmode=require&connect_timeout=30

(If using sslmode=require still fails, test sslmode=verify-full).

B. Direct IP vs IPv6 Resolution on Windows

Windows frequently attempts IPv6 resolution first. If your local network or ISP has partial IPv6 routing, Node may fall back to IPv4 faster than Rust's socket connection timeout. Test forcing the IPv4 address if applicable, or increase connect_timeout=30.

---

4. Supported Workaround to Apply Migrations

If you need to unblock migration execution immediately while troubleshooting the native engine socket on Windows:

1. Apply migrations using prisma db execute (which also accepts SQL files), or:
2. Apply migration SQL files directly using a small script with @prisma/adapter-pg or pg:
   Because pg connects cleanly, you can run:

   import fs from "fs";
   import path from "path";
   import { Client } from "pg";
   
   async function runMigrations() {
     const client = new Client({ connectionString: process.env.DATABASE_URL_UNPOOLED });
     await client.connect();
     // Read and apply migration.sql in transaction
     const sql = fs.readFileSync(path.join("prisma/migrations", "<migration_dir>", "migration.sql"), "utf-8");
     await client.query(sql);
     await client.end();
   }
   runMigrations();

   Once applied, when the schema engine connects it will see the tables and match the migration checksums.

[RRINNOVATION]

Thank you for your email and support, with your help the issue is solved Regards

…

On Thu, 29 Oct, 2026, 6:37 am Praveen Kumar, ***@***.***> wrote: The reason this happens is due to the difference between *how Node.js handles TLS/DNS vs. how Prisma's native Rust Schema Engine handles them on Windows*: ------------------------------ 1. Why pg / @prisma/adapter-pg works, but Schema Engine returns P1001 - *Node.js runtime ***@***.***/adapter-pg and pg)*: Uses Node's built-in JavaScript/C++ network stack, which ships with Mozilla's pre-compiled CA certificate bundle and Node's DNS resolver. - *Prisma CLI (prisma migrate status, db pull)*: Does *not* use @prisma/adapter-pg. Instead, the CLI spawns the native Rust binary ( schema-engine-windows.exe), which connects using Rust's tokio-postgres and the Windows system certificate store (rustls-native-certs / Schannel). When connecting to Neon (*.neon.tech) from Windows, two common discrepancies cause P1001 in Rust while succeeding in Node: 1. *Server Name Indication (SNI) & TLS Handshake*: Neon multiplexes connections based on the SNI hostname (ep-xyz-123456.region.neon.tech). If the connection string lacks an explicit sslmode=require, or if a Windows firewall/VPN/proxy intercepts the TLS handshake, Node's pg driver may tolerate it while Rust's strict TLS verification rejects the socket before sending the startup packet. 2. *Windows Certificate Store vs. Let's Encrypt / ISRG Root*: The Rust engine queries the Windows user/machine certificate store. If the ISRG Root X1 or intermediate CA certificate is missing or not synced in the Windows trust store, the Rust TLS handshake fails immediately with a socket disconnect, which Prisma surfaces as P1001 (Cannot reach database server). ------------------------------ 2. How to reveal the exact underlying Rust error (Safe Diagnostics) Run the command with the RUST_LOG environment variable enabled. This forces the native Schema Engine to print its exact socket and TLS error before returning P1001, without printing your credentials: In PowerShell: $env:RUST_LOG="debug,quaint=trace"$env:DEBUG="prisma:schema-engine*" npx prisma migrate status --config=prisma.stage10.config.ts In the output, look specifically for lines like: - tls: certificate verify failed: UnknownIssuer (Missing root CA in Windows store) - tls: invalid peer name (SNI mismatch) - connection reset by peer / timeout (Port 5432 routing / MTU issue) ------------------------------ 3. Immediate Fixes to Try A. Explicit SSL & Connect Timeout Parameters Ensure your Neon unpooled connection string explicitly specifies: ***@***.***/neondb?sslmode=require&connect_timeout=30 *(If using sslmode=require still fails, test sslmode=verify-full).* B. Direct IP vs IPv6 Resolution on Windows Windows frequently attempts IPv6 resolution first. If your local network or ISP has partial IPv6 routing, Node may fall back to IPv4 faster than Rust's socket connection timeout. Test forcing the IPv4 address if applicable, or increase connect_timeout=30. ------------------------------ 4. Supported Workaround to Apply Migrations If you need to unblock migration execution immediately while troubleshooting the native engine socket on Windows: 1. *Apply migrations using prisma db execute* (which also accepts SQL files), or: 2. *Apply migration SQL files directly using a small script with @prisma/adapter-pg or pg*: Because pg connects cleanly, you can run: import fs from "fs";import path from "path";import { Client } from "pg"; async function runMigrations() { const client = new Client({ connectionString: process.env.DATABASE_URL_UNPOOLED }); await client.connect(); // Read and apply migration.sql in transaction const sql = fs.readFileSync(path.join("prisma/migrations", "<migration_dir>", "migration.sql"), "utf-8"); await client.query(sql); await client.end();}runMigrations(); Once applied, when the schema engine connects it will see the tables and match the migration checksums. — Reply to this email directly, view it on GitHub <#30879?email_source=notifications&email_token=BTOL37SVFKI6CF7HMKJ22BT5WKJ4NA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJSGU3TAMRTUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-19257023>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BTOL37QQWYVEPOPGPBOCOAD5WKJ4NAVCNFSNUABIKJSXA33TNF2G64TZHMYTSMRZGI2TQMZTHNCGS43DOVZXG2LPNY5TCMJRGM3TOMBUUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BTOL37T4VQCMIAX6FNQEYYD5WKJ4NA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJSGU3TAMRTUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/BTOL37RUANVHJV44KYXMUWT5WKJ4NA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJSGU3TAMRTUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[praveen-kumary]

The reason this happens is due to the difference between how Node.js handles TLS/DNS vs. how Prisma's native Rust Schema Engine handles them on Windows:

---

1. Why pg / @prisma/adapter-pg works, but Schema Engine returns P1001

• Node.js runtime (@prisma/adapter-pg and pg): Uses Node's built-in JavaScript/C++ network stack, which ships with Mozilla's pre-compiled CA certificate bundle and Node's DNS resolver.
• Prisma CLI (prisma migrate status, db pull): Does not use @prisma/adapter-pg. Instead, the CLI spawns the native Rust binary (schema-engine-windows.exe), which connects using Rust's tokio-postgres and the Windows system certificate store (rustls-native-certs / Schannel).

When connecting to Neon (*.neon.tech) from Windows, two common discrepancies cause P1001 in Rust while succeeding in Node:

1. Server Name Indication (SNI) & TLS Handshake: Neon multiplexes connections based on the SNI hostname (ep-xyz-123456.region.neon.tech). If the connection string lacks an explicit sslmode=require, or if a Windows firewall/VPN/proxy intercepts the TLS handshake, Node's pg driver may tolerate it while Rust's strict TLS verification rejects the socket before sending the startup packet.
2. Windows Certificate Store vs. Let's Encrypt / ISRG Root: The Rust engine queries the Windows user/machine certificate store. If the ISRG Root X1 or intermediate CA certificate is missing or not synced in the Windows trust store, the Rust TLS handshake fails immediately with a socket disconnect, which Prisma surfaces as P1001 (Cannot reach database server).

---

2. How to reveal the exact underlying Rust error (Safe Diagnostics)

Run the command with the RUST_LOG environment variable enabled. This forces the native Schema Engine to print its exact socket and TLS error before returning P1001, without printing your credentials:

In PowerShell:

$env:RUST_LOG="debug,quaint=trace"
$env:DEBUG="prisma:schema-engine*"
npx prisma migrate status --config=prisma.stage10.config.ts

In the output, look specifically for lines like:

• tls: certificate verify failed: UnknownIssuer (Missing root CA in Windows store)
• tls: invalid peer name (SNI mismatch)
• connection reset by peer / timeout (Port 5432 routing / MTU issue)

---

3. Immediate Fixes to Try

A. Explicit SSL & Connect Timeout Parameters

Ensure your Neon unpooled connection string explicitly specifies:

postgresql://user:password@ep-xyz-123456.us-east-2.aws.neon.tech/neondb?sslmode=require&connect_timeout=30

(If using sslmode=require still fails, test sslmode=verify-full).

B. Direct IP vs IPv6 Resolution on Windows

Windows frequently attempts IPv6 resolution first. If your local network or ISP has partial IPv6 routing, Node may fall back to IPv4 faster than Rust's socket connection timeout. Test forcing the IPv4 address if applicable, or increase connect_timeout=30.

---

4. Supported Workaround to Apply Migrations

If you need to unblock migration execution immediately while troubleshooting the native engine socket on Windows:

1. Apply migrations using prisma db execute (which also accepts SQL files), or:
2. Apply migration SQL files directly using a small script with @prisma/adapter-pg or pg:
   Because pg connects cleanly, you can run:

   import fs from "fs";
   import path from "path";
   import { Client } from "pg";
   
   async function runMigrations() {
     const client = new Client({ connectionString: process.env.DATABASE_URL_UNPOOLED });
     await client.connect();
     // Read and apply migration.sql in transaction
     const sql = fs.readFileSync(path.join("prisma/migrations", "<migration_dir>", "migration.sql"), "utf-8");
     await client.query(sql);
     await client.end();
   }
   runMigrations();

   Once applied, when the schema engine connects it will see the tables and match the migration checksums.