Neon + Lambda in a VPC: you need NAT or the connection times out

TL;DR: Lambda in a VPC has no internet route by default, so connections to Neon hang until timeout. The fix is networking, not the connection string. Agents rotate passwords, switch pooled/direct, and raise timeouts, but the packets never leave the VPC: no NAT gateway means no route to Neon's public endpoints. Checklist - Timeouts only from VPC-attached functions, fine from local: suspect NAT. - Keep the pooled connection string regardless; this is orthogonal to pooling. - Security groups must allow outbound 5432 and 443.

The fix

1. Lambda in a VPC needs a NAT gateway (or VPC endpoints, which do not apply to Neon) in a public subnet, with the function's subnets private and routed through it.
2. If you do not need the VPC at all, take the function out of the VPC; it is the simplest fix.
3. Verify with a minimal test: from the same VPC config, curl an HTTPS URL. If that fails too, it is the network, not Postgres.
4. Timeouts only from VPC-attached functions, fine from local: suspect NAT.
5. Keep the pooled connection string regardless; this is orthogonal to pooling.
6. Security groups must allow outbound 5432 and 443.

When to use this

• This covers exactly what the title says: Neon + Lambda in a VPC.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with Neon; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Not pinned to a specific version; follows current Neon behavior.