Replit PostgreSQL concurrent connection limits in autoscale deployments

Replit's managed PostgreSQL service enforces concurrent connection limits per database instance, and bursty traffic in autoscale deployments can produce intermittent errors that resemble client-side pool exhaustion. Because autoscale instances may scale to zero, connection reuse across cold starts is not guaranteed, which can increase churn against the database. The platform does not expose a built-in server-side connection pooler for PostgreSQL, so application-level pool configuration remains the primary mitigation.

The exact numeric connection ceiling is plan-sensitive and should be verified against current Replit documentation before relying on it operationally. When sizing a client-side pool, the aggregate number of connections from all active deployment instances competing for the same database must be considered, but the platform's enforced ceiling is not always clearly published. This creates uncertainty about whether pool exhaustion originates from the application pool, the platform limit, or both.

What is the documented concurrent connection ceiling for Replit PostgreSQL, and does it vary by deployment type or plan? How does scale-to-zero behavior in autoscale deployments affect connection persistence and cold-start churn? Should client-side pool sizing be calculated against the platform's per-database limit or against per-instance limits?