P
Prisma•6mo ago
Bibi_la_truite

Problem: npx prisma migrate dev fails with Error P3006 (but database is reachable)

I'm running into an issue with Prisma Migrate and can't find a solution after trying multiple approaches. --- Initial Setup I started with an existing PostgreSQL DB (running on Windows Server, not Docker). Here's what I did: 1. Pulled the schema: 
   npx prisma db pull
 
   npx prisma db pull
2. Created initial migration folder: 
   mkdir -p prisma/migrations/0_init
 
   mkdir -p prisma/migrations/0_init
3. Generated the SQL migration: 
   npx prisma migrate diff --from-empty --to-schema-datamodel prisma/schema.prisma --script > prisma/migrations/0_init/migration.sql
 
   npx prisma migrate diff --from-empty --to-schema-datamodel prisma/schema.prisma --script > prisma/migrations/0_init/migration.sql
4. Marked migration as applied: 
   npx prisma migrate resolve --applied 0_init
 
   npx prisma migrate resolve --applied 0_init
5. Then ran: 
   npx prisma migrate dev
   
   npx prisma migrate dev
--- The Problem When running npx prisma migrate dev, I get: 
Error: P3006

Migration `0_init` failed to apply cleanly to the shadow database. 
Error code: P1001
Error:
Can't reach database server at `192.168.1.228:5432`

Please make sure your database server is running at `192.168.1.228:5432`.
Error: P3006

Migration `0_init` failed to apply cleanly to the shadow database. 
Error code: P1001
Error:
Can't reach database server at `192.168.1.228:5432`

Please make sure your database server is running at `192.168.1.228:5432`.
However, the DB is reachable — npx prisma db pull works fine. --- What I Tried * Set a valid shadowDatabaseUrl → no change * Tried migrate resolve --rolled-back and --applied * Tested with a minimal DB → same error * Confirmed PostgreSQL user is a superuser * Not running in Docker → not a container issue --- Info * DB: PostgreSQL (Windows Server) * Backend: NestJS * Prisma/CLI version: 6.9.0 --- Question Has anyone faced an issue where prisma migrate dev can't reach the shadow DB, even though db pull works? Could this be specific to how Prisma handles shadow DBs on non-Docker Windows setups? Any help appreciated!
6 Replies
Prisma AI Help
Prisma AI Help•6mo ago
You're in no rush, so we'll let a dev step in. Enjoy your coffee, or drop into #ask-ai if you get antsy for a second opinion!
Nurul
Nurul•6mo ago
Hey! Can you share your shadowDatabaseUrl connection string? I assume your shadow database is also running locally. What happens if you try to connect to the shadowdatabase from an IDE like Tableplus, pgAdmin etc. Are you able to connect?
Bibi_la_truite
Bibi_la_truiteOP•6mo ago
Hi ! Thanks for your answer 🙂 Here is the shadowDatabaseUrl: postgresql://fakeUser:fakePassword@192.168.1.228:5432/dbhf_shadow?schema=public&connect_timeout=300 And yes I tried to connect using PgAdmin and it worked... --- UPDATE --- Here are logs I got in my PosgreSQL server after using the npx prisma migrate dev command: 
2025-06-16 11:11:50 CEST LOG:  connection received: host=192.168.0.97 port=55992
2025-06-16 11:11:50 CEST LOG:  connection authenticated: identity="myUser" method=scram-sha-256 (D:/pgsql_data/pg_hba.conf:124)
2025-06-16 11:11:50 CEST LOG:  connection authorized: user=myUser database=dbhf
2025-06-16 11:11:50 CEST LOG:  disconnection: session time: 0:00:00.038 user=myUser database=dbhf host=192.168.0.97 port=55992

2025-06-16 11:11:50 CEST LOG:  connection received: host=192.168.0.97 port=55993
2025-06-16 11:11:50 CEST LOG:  connection authenticated: identity="myUser" method=scram-sha-256 (D:/pgsql_data/pg_hba.conf:124)
2025-06-16 11:11:50 CEST LOG:  connection authorized: user=myUser database=dbhf
2025-06-16 11:11:51 CEST LOG:  connection received: host=192.168.0.97 port=55994
2025-06-16 11:11:51 CEST LOG:  connection authenticated: identity="myUser" method=scram-sha-256 (D:/pgsql_data/pg_hba.conf:124)
2025-06-16 11:11:51 CEST LOG:  connection authorized: user=myUser database=prisma_migrate_shadow_db_fb443868-ddcc-4e36-bc75-76f333a1af13
2025-06-16 11:11:51 CEST LOG:  disconnection: session time: 0:00:00.146 user=myUser database=prisma_migrate_shadow_db_fb443868-ddcc-4e36-bc75-76f333a1af13 host=192.168.0.97 port=55994

2025-06-16 11:11:51 CEST LOG:  checkpoint starting: immediate force wait
2025-06-16 11:11:52 CEST LOG:  checkpoint complete: wrote 7 buffers (0.0%); 0 WAL file(s) added, 1 removed, 0 recycled; write=0.010 s, sync=0.029 s, total=0.076 s; sync files=7, longest=0.011 s, average=0.005 s; distance=4550 kB, estimate=37795 kB; lsn=61/5D26A488, redo lsn=61/5D26A430

2025-06-16 11:11:52 CEST LOG:  could not receive data from client: unrecognized winsock error 10054
2025-06-16 11:11:52 CEST LOG:  disconnection: session time: 0:00:02.101 user=myUser database=dbhf host=192.168.0.97 port=55993
2025-06-16 11:11:50 CEST LOG:  connection received: host=192.168.0.97 port=55992
2025-06-16 11:11:50 CEST LOG:  connection authenticated: identity="myUser" method=scram-sha-256 (D:/pgsql_data/pg_hba.conf:124)
2025-06-16 11:11:50 CEST LOG:  connection authorized: user=myUser database=dbhf
2025-06-16 11:11:50 CEST LOG:  disconnection: session time: 0:00:00.038 user=myUser database=dbhf host=192.168.0.97 port=55992

2025-06-16 11:11:50 CEST LOG:  connection received: host=192.168.0.97 port=55993
2025-06-16 11:11:50 CEST LOG:  connection authenticated: identity="myUser" method=scram-sha-256 (D:/pgsql_data/pg_hba.conf:124)
2025-06-16 11:11:50 CEST LOG:  connection authorized: user=myUser database=dbhf
2025-06-16 11:11:51 CEST LOG:  connection received: host=192.168.0.97 port=55994
2025-06-16 11:11:51 CEST LOG:  connection authenticated: identity="myUser" method=scram-sha-256 (D:/pgsql_data/pg_hba.conf:124)
2025-06-16 11:11:51 CEST LOG:  connection authorized: user=myUser database=prisma_migrate_shadow_db_fb443868-ddcc-4e36-bc75-76f333a1af13
2025-06-16 11:11:51 CEST LOG:  disconnection: session time: 0:00:00.146 user=myUser database=prisma_migrate_shadow_db_fb443868-ddcc-4e36-bc75-76f333a1af13 host=192.168.0.97 port=55994

2025-06-16 11:11:51 CEST LOG:  checkpoint starting: immediate force wait
2025-06-16 11:11:52 CEST LOG:  checkpoint complete: wrote 7 buffers (0.0%); 0 WAL file(s) added, 1 removed, 0 recycled; write=0.010 s, sync=0.029 s, total=0.076 s; sync files=7, longest=0.011 s, average=0.005 s; distance=4550 kB, estimate=37795 kB; lsn=61/5D26A488, redo lsn=61/5D26A430

2025-06-16 11:11:52 CEST LOG:  could not receive data from client: unrecognized winsock error 10054
2025-06-16 11:11:52 CEST LOG:  disconnection: session time: 0:00:02.101 user=myUser database=dbhf host=192.168.0.97 port=55993
Upasana
Upasana•6mo ago
hey did you find a solution? Have been struggling with exact same problem
Bibi_la_truite
Bibi_la_truiteOP•6mo ago
Hello ! You can see in the PostgreSQL log file above this error: 2025-06-16 11:11:52 CEST LOG: could not receive data from client: unrecognized winsock error 10054 This is a windows error and here is the explanation according to official documentation: 
Connection reset by peer.
An existing connection was forcibly closed by the remote host. This normally results if the peer application on the remote host is suddenly stopped, the host is rebooted, the host or remote network interface is disabled, or the remote host uses a hard close (see setsockopt for more information on the SO_LINGER option on the remote socket). This error may also result if a connection was broken due to keep-alive activity detecting a failure while one or more operations are in progress. Operations that were in progress fail with WSAENETRESET. Subsequent operations fail with WSAECONNRESET.
Connection reset by peer.
An existing connection was forcibly closed by the remote host. This normally results if the peer application on the remote host is suddenly stopped, the host is rebooted, the host or remote network interface is disabled, or the remote host uses a hard close (see setsockopt for more information on the SO_LINGER option on the remote socket). This error may also result if a connection was broken due to keep-alive activity detecting a failure while one or more operations are in progress. Operations that were in progress fail with WSAENETRESET. Subsequent operations fail with WSAECONNRESET.
This means that the issue is not due to prisma but to something else that I didn't find... I tried to reproduce the same issue on a LinuxOS and a MacOS and it didn't fail so I think it's an OS problem. I can't dig more on this issue now but but it was all the information that I have so far 🙂
Matondo simba paul merite
Matondo simba paul merite•6mo ago
I can have the code far away from access ?

Did you find this page helpful?