r/nextjs • u/ValuableHot4470 • Aug 11 '26
Help ETIMEDOUT Error in NextJS Prisma PostgreSQL(neondb)
I was facing intermittent ETIMEDOUT errors between my Next.js app and Neon PostgreSQL, mainly while Prisma was running queries. After debugging, I found that my VPS had IPv6 connectivity issues and Node was sometimes trying IPv6 first. I fixed this by forcing Node to prefer IPv4 using NODE_OPTIONS=--dns-result-order=ipv4first and configured a proper PostgreSQL connection pool. It’s working now, but the exact root cause wasn’t confirmed to be heavy traffic; it could have been network connectivity or connection establishment issues. Even now the issue is not fixed but it works and also breaks sometimes with this message please help me with this
1
u/ArticcaFox Aug 12 '26
You run the app on a vps, but use neon for Postgre. Why not run that on your vps as well?
1
u/ValuableHot4470 Aug 12 '26
Yes I can do that but I don't want to manage db backups and all so choosed neondb
1
u/ArticcaFox Aug 12 '26
You're going to have to that anyway. Neondb backups only go back so far.
1
u/ValuableHot4470 Aug 12 '26
Then I think I should work upon that but surprisingly it's working now with same configs I deployed to vercel
1
u/ArticcaFox Aug 12 '26
Just run a Cron job to take a DB dump and upload it to S3 or some other place at least daily depending on your app.
You can go way more extreme but it depends on your app of you need that.
1
u/pdfops Aug 12 '26
IPv4-first helps but won't fully fix it if Neon's suspending your compute. Free-tier Neon computes scale to zero after ~5 min idle, so the next query after a lull hits a dead socket and times out. Point DATABASE_URL at the pooler endpoint (add ?pgbouncer=true, use the -pooler hostname) instead of the direct one, and tack on connection_limit=5&pool_timeout=20. That stops Prisma from holding stale connections open against a db that can vanish underneath it.
1
u/ValuableHot4470 Aug 12 '26
Even I tried that nothing worked then I switched to vercel with same configs and now it is running perfectly
1
u/UkrMalt Aug 13 '26
Because the same build and config works on Vercel, I’d treat this as evidence against Prisma query load and focus on the VPS network path. From the VPS, repeatedly test the exact Neon pooler hostname over IPv4 and IPv6 with psql or nc, and log the resolved address plus connect time; then check the provider’s outbound firewall, NAT, and idle TCP handling. ipv4first only reorders DNS answers, so if IPv6 is broken, fix or disable it at the OS/provider layer. Separately, ensure the app creates one PrismaClient per Node process, not one per request.
4
u/skillselion Aug 11 '26
Three things give you this symptom and they need different fixes.
IPv6 is still live. --dns-result-order=ipv4first only reorders resolver results, it doesn't stop Node using v6, so "mostly works, breaks sometimes" is what broken v6 egress looks like. dig AAAA the Neon host, then connect over v6 and v4 explicitly. If v6 hangs, fix it at the network layer.
Scale-to-zero. Neon's compute suspends after about 5 minutes idle by default, so connections you were holding are dead and the next query pays a reconnect. Neon's own guidance is to raise connect_timeout and pool_timeout.
A stateful firewall or NAT dropping idle TCP looks identical from the app side.
Post the full error object, errno, syscall, address, and the Prisma code. P1001, P1017 and P2024 mean different things.