Prisma P1001: Can't reach database server in production
The errorError: P1001: Can't reach database server at `db.example.com:5432`
Please make sure your database server is running at `db.example.com:5432`.Prisma can't open a network connection to the database at that host and port. Either the address is wrong for production, or the database doesn't accept connections from where your app runs.
Why it happens
P1001 means the connection never got established: no answer before the timeout. It is not a password problem (that is P1000). Common reasons in production:
- The production database URL is missing, wrong, or still points at your laptop.
- The database only accepts connections from allowlisted IP addresses. Your laptop is on the list; your host isn't. Serverless hosts usually don't have fixed outbound IPs.
- The address only works over IPv6. Supabase, for example, says its direct connection is IPv6 unless you buy the IPv4 add-on, while its pooler works over IPv4.
- The database is paused, overloaded, or on a different port than the URL says.
Fix it by hand
- Check the host and port Prisma used. The error message names them. Compare with your provider's connection page. If it says
localhost, your productionDATABASE_URLisn't set; see the ECONNREFUSED fix. - Test the same URL from your machine. Run a read-only Prisma command against the production URL, for example
npx prisma migrate status. If it also fails from your laptop, the URL or the database is the problem, not your host. - Open the database's network access. In your provider's network or IP allowlist settings, allow your host's outbound IPs. If your host has no fixed IPs, the usual options are a pooled or serverless endpoint from the provider, or allowing all IPs with a strong password and SSL required.
- Use the pooled connection string for serverless. Serverless functions open many short-lived connections. Supabase recommends its transaction pooler (port
6543) for that, and says Prisma needspgbouncer=trueadded to the URL in transaction mode, because prepared statements aren't supported there. - Add SSL if the provider requires it, for example
?sslmode=requireon a Postgres URL. - Update the production variable and redeploy. Then load a page that queries the database.
Stop it happening again
- Keep separate database URLs per environment, and the pooled URL wherever your code runs on serverless functions.
- Before launch, run one real query from a deployed preview, not only from your laptop.
- Write down which IPs or networks your database accepts, so a host change doesn't silently break it.
Broke After Deploy $9
Broke After Deploy flags database URLs that point at your computer, schema changes never applied to production, and a new database connection opened on every request. For network rules it can't see, it tells you exactly which settings page to check.
- Checks your project for 37 known causes of "works locally, breaks in production" and runs your production build.
- Paste the error and it finds the cause in your code, then lists what will break next.
- Verdict first. Every finding shows the file and line, what it breaks, and the fix as a diff that is applied only with your OK.
Broke After Deploy: how it works, with examples · Install guide
Works with Claude Code, Claude.ai, Cursor, Codex and other agents that read SKILL.md files. No installs, no accounts, works offline. No-questions refund.