Quick answer
Neon documents compute max_connections as Compute-size dependent, up to 4,000. Smaller computes expose lower direct PostgreSQL connection capacity.
Verified Aug 22, 2026Official source
Current limits
| Constraint | Current value | Scope | Verified source |
|---|---|---|---|
| compute max_connectionsSmaller computes expose lower direct PostgreSQL connection capacity. | Compute-size dependent, up to 4,000 | Per compute | NeonAug 22, 2026 |
Why does this limit matter?
Autoscaling application instances can multiply pools beyond a small compute's direct capacity.
This value is scoped to Per compute; a different plan, runtime, model, endpoint, region, or account can produce a different effective constraint.
What should you check?
- Read compute size and max_connections, then multiply every application pool by live instances.
- Confirm the exact plan, model, runtime, endpoint, region, and account that serve the failing workload.
- Record the observed value, response headers or configuration, timestamp, and source without logging secrets.
Important caveats
- Reserved and operational connections reduce what application clients can safely consume.
- Treat the official source and live account configuration as authoritative if they differ from this verified snapshot.
HyperObserve reports the documented platform constraint. Your application, SDK, gateway, provider, region, or account can impose a lower effective limit.
Related