PostgreSQL connection timeout when registering with Better Auth and Prisma

[yvssineyh269]

Hello,

I'm encountering an error when trying to sign up in my Next.js app using Better Auth and Prisma 7. The /signup page displays correctly (GET /signup returns a 200 status code), but the sign-up request fails :

POST /api/auth/sign-up/email 500
PrismaClientKnownRequestError
code: ETIMEDOUT
meta: { modelName: 'User' }

The error occurs when Better Auth uses Prisma to execute findFirst() on the User model. The query takes about 18 seconds before failing. I also saw a warning regarding the SSL modes in pg-connection-string, but I’m not sure if it’s related to this error.

How can I determine whether this timeout is due to PostgreSQL availability, the connection configuration, the network, or SSL, and what checks do you recommend to resolve it?

GET /signup 200 in 658ms (next.js: 129ms, proxy.ts: 36ms, application-code: 493ms)
2026-10-08T05:28:18.109Z ERROR [Better Auth]: PrismaClientKnownRequestError Error [PrismaClientKnownRequestError]:
Invalid db[model].findFirst() invocation in
/home/yvssi/IdeaProjects/census-app/.next/dev/server/chunks/[root-of-the-server]__182wzns._.js:1086:52

1083 map.set(key, getModelName(joinModel));
1084 }
1085 const selects = convertSelect(select, model, join);
→ 1086 const result = await db[model].findFirst(

at ignore-listed frames {

code: 'ETIMEDOUT',
meta: { modelName: 'User' },
clientVersion: '7.10.0'
}

SERVER_ERROR: Error [PrismaClientKnownRequestError]:

Invalid db[model].findFirst() invocation in
/home/yvssi/IdeaProjects/census-app/.next/dev/server/chunks/[root-of-the-server]__182wzns._.js:1086:52

1083 map.set(key, getModelName(joinModel));
1084 }
1085 const selects = convertSelect(select, model, join);
→ 1086 const result = await db[model].findFirst(

at ignore-listed frames {

code: 'ETIMEDOUT',
meta: { modelName: 'User' },
clientVersion: '7.10.0'
}
POST /api/auth/sign-up/email 500 in 18.2s (next.js: 1648ms, proxy.ts: 54ms, application-code: 16.5s)
Reload env: .env

[kgeminicdev]

The shape of the error tells you most of it. When adapter-pg recognises a socket error it maps it to a Prisma code (ETIMEDOUT becomes P1008, ECONNREFUSED/ENOTFOUND become P1001) and puts driverAdapterError in meta. You got the raw code: 'ETIMEDOUT' with only modelName in meta. That happens when the error has no syscall/errno, so it falls through unmapped:

orm/packages/adapter-pg/src/errors.ts

Lines 249 to 263 in e92bc46

	function isSocketError(error: any): error is Error & {
	code: 'ENOTFOUND' | 'ECONNREFUSED' | 'ECONNRESET' | 'ETIMEDOUT'
	syscall: string
	errno: number
	address?: string
	port?: number
	hostname?: string
	} {
	return (
	typeof error.code === 'string' &&
	typeof error.syscall === 'string' &&
	typeof error.errno === 'number' &&
	SOCKET_ERRORS.has(error.code as string)
	)
	}

That's what Node throws when the hostname resolves to more than one address (IPv6 + IPv4, or several A records) and every connect attempt fails: an AggregateError carrying the attempts' code. So the TCP connection to Postgres was never established. It isn't SSL (TLS only starts after TCP connects, and TLS failures map to a different error) and it isn't auth. The pg-connection-string warning only says sslmode=require/prefer are now treated as verify-full. Unrelated.

Check reachability outside Prisma, with the same URL and from the same shell that runs next dev:

// check.mjs
import dns from 'node:dns/promises'
import net from 'node:net'

const u = new URL(process.env.DATABASE_URL)
console.log(await dns.lookup(u.hostname, { all: true }))
const s = net.connect({ host: u.hostname, port: Number(u.port || 5432), timeout: 5000 })
s.on('connect', () => { console.log('tcp ok'); s.end() })
s.on('timeout', () => { console.log('tcp timeout'); s.destroy() })
s.on('error', (e) => console.log(e.name, e.code, e.errors?.map((x) => `${x.address} ${x.code}`)))

node --env-file=.env check.mjs

If that times out too, it's the network and not Prisma. Usual suspects: Postgres not listening on that interface, a firewall or IP allowlist on a hosted DB, or, if this is WSL2, localhost not reaching a Postgres running on the Windows side. Once it prints tcp ok, the Prisma query should go through, or fail with a real Postgres/TLS error you can act on.

[kgeminicdev]

That output settles it. The IPv6 ENETUNREACH is just your machine having no IPv6 route, so ignore it. The IPv4 ETIMEDOUT is the real problem: packets to port 5432 are being dropped silently somewhere.

Before you go into the AWS console, note that one hostname resolving to three IPv4 and three IPv6 addresses usually means a managed proxy or pooler endpoint, not a single RDS instance. Which one you have changes where you look:

• Your own RDS instance: add an inbound rule on its security group for TCP 5432 from your public IP (curl -4 ifconfig.me). Also make sure the instance is set to "Publicly accessible" and sits in a subnet with a route to an internet gateway. A security group rule alone won't help if either of those is off.
• A hosted Postgres provider: there's no security group for you to edit. Check the provider's IP allow list or network restrictions page instead.

It's also worth ruling out your own network, because a lot of office, campus and ISP networks block outbound 5432. Run the same check.mjs from a phone hotspot. If it prints tcp ok there, the block is on your side, not AWS.

Once check.mjs prints tcp ok, sign-up should go through, or fail with a real Postgres or TLS error you can act on.

[yvssineyh269]

Hi @kgeminicdev ,

I ran the check.mjs script as you suggested, and the result confirms the network issue. Here’s the output:

yvssi@kratos-engine:~/IdeaProjects/census-app$ node --env-file=.env check.mjs
[
  { address: '54.153.234.207', family: 4 },
  { address: '54.206.85.193', family: 4 },
  { address: '3.106.69.51', family: 4 },
  { address: '2406:da1c:b7c:d11:b952:e163:87c0:5972', family: 6 },
  { address: '2406:da1c:b7c:d20:2c57:4c4d:e935:9480', family: 6 },
  { address: '2406:da1c:b7c:d0e:9858:9714:c422:b17b', family: 6 }
]
AggregateError ETIMEDOUT [
  '3.106.69.51 ETIMEDOUT',
  '2406:da1c:b7c:d11:b952:e163:87c0:5972 ENETUNREACH',
  '54.153.234.207 ETIMEDOUT',
  '2406:da1c:b7c:d0e:9858:9714:c422:b17b ENETUNREACH',
  '54.206.85.193 ETIMEDOUT',
  '2406:da1c:b7c:d20:2c57:4c4d:e935:9480 ENETUNREACH'
]

As you pointed out, this confirms that the TCP connection to Postgres is never established. The IPv4 addresses time out (ETIMEDOUT) and IPv6 is unreachable (ENETUNREACH).

This looks like a Security Group issue on AWS (since the DB is hosted there). I’ll check if the inbound rule on port 5432 allows traffic from my server’s public IP.

Thanks for the detailed diagnosis !

[bintangyudhis]

Since your check already shows the TCP connection is never established (every resolved IP times out, IPv6 is unreachable), you can rule out most of the stack: it's not Better Auth, not Prisma, and not SSL. The SSL warning is unrelated — pg-connection-string warns that sslmode=require/prefer will be treated as verify-full in a future pg version, but TLS only starts after the TCP connection succeeds, and yours never does. Timeouts on the raw socket mean packets are being silently dropped somewhere between your machine and the database.

For a local dev machine connecting to a database on AWS, the suspects in order:

1. The security group doesn't allow your current public IP. Check what your public IP is right now and compare it with the SG inbound rule for 5432. Home/office IPs change — "it worked last week" plus this exact symptom is usually a stale whitelist entry.
2. The database isn't publicly reachable at all. If "Publicly accessible" is off, or the DB sits in private subnets, no security-group rule will ever let your laptop in — there's simply no route back. In that case either use a bastion/SSH tunnel, or run a local Postgres (e.g. Docker) for development and point DATABASE_URL at the cloud DB only in deployment.
3. Your own network blocks outbound 5432. Some ISPs and office/campus networks do. This is more common than people expect.

One test separates 1+2 from 3 in a minute: connect your machine to a phone hotspot and run the same check script. If it connects from the hotspot, the problem is your normal network or its public IP (suspects 1/3). If it still times out everywhere, it's the AWS side (suspect 2, or an SG/NACL rule).

And to take Prisma completely out of the equation while testing, try from the same machine:

nc -vz <your-db-host> 5432
# or
psql "$DATABASE_URL" -c 'select 1'

If those time out too, no client-side change will fix it — the fix lives in the network path. My money is on #1 or #3, given DNS resolves fine but every single IP swallows the packets.