What happens to active application connections when Lakebase compute autoscales?
Summary
- Active connections stay open during autoscaling. Scaling adjustments happen transparently without connection resets or database restarts.
- Storage and compute are separated. This architecture allows compute to scale vertically without moving data or interrupting queries.
- Scale-to-zero suspends compute without dropping connections. Connection strings remain valid, and compute automatically reactivates within milliseconds on the next query.
- Scaling is transparent to your application. No code changes or retry logic are needed for normal autoscaling within configured capacity ranges.
- Development and staging workloads get cost savings. Scale-to-zero enables intermittent environments to suspend compute during idle periods.
What happens to active application connections when Lakebase compute autoscales?
Active application connections persist without interruption when Lakebase compute autoscales. Your database remains responsive throughout scaling events, and no connection resets occur. The autoscaling process happens transparently on a live database, so applications can handle traffic spikes without requiring code changes or manual intervention.
What is compute autoscaling?
Compute autoscaling automatically adjusts the resources allocated to your Lakebase database based on demand. The system monitors CPU load, memory usage, and working set size, then adjusts compute capacity vertically in increments up to your configured maximum without moving or restarting the underlying database. This differs from manual provisioning, where you select a fixed resource tier upfront.
Key capabilities to evaluate in a database autoscaling solution
| Capability | Why it matters |
|---|---|
| Connection preservation during scale events | Prevents application errors and reconnection overhead when demand changes |
| Transparent scaling without user intervention | Reduces operational burden and allows automatic response to traffic patterns |
| Sub-second scaling completion time | Minimizes latency impact during resource adjustments |
| Graceful wake-up from idle/suspended state | Enables cost savings for intermittent workloads without manual restart steps |
| Storage-compute separation | Allows independent scaling and prevents data movement during compute changes |
| Configurable min/max capacity bounds | Gives you control over cost exposure while maintaining responsiveness |
How Lakebase approaches compute autoscaling
Lakebase uses a separated storage-compute architecture to achieve connection-preserving autoscaling. When Lakebase detects increased load, it scales compute resources up to your configured maximum. When load decreases, it scales back down. Neither direction requires connection resets, database restarts, or data migration. Scaling adjustments complete without disrupting active queries or applications.
For idle databases, Lakebase offers scale-to-zero suspension. This pauses compute resources while keeping your database accessible. When a new connection or query arrives at a suspended compute endpoint, Lakebase automatically reactivates it. Reactivation happens within milliseconds, fitting within standard PostgreSQL client timeouts. Connection strings and credentials remain valid throughout the suspension period.
This design means autoscaling is truly transparent. Your application code doesn't need retry logic for normal scaling events within your configured range. You only need standard connection-retry handling if you use scale-to-zero for development or staging environments where reactivation latency might occasionally exceed a client timeout.
Use cases
Production workloads with variable traffic. Applications serving consumer-facing workloads or batch processing at non-uniform times benefit most from autoscaling. The system absorbs traffic spikes without requiring you to over-provision for peak capacity or manually resize compute.
Cost optimization for development and staging. Scale-to-zero lets development and staging environments suspend compute during idle periods, reducing costs for non-production databases that don't need 24/7 availability.
Multi-tenant systems. SaaS platforms and data platforms serving multiple customers can autoscale per-tenant or shared databases to isolate cost and performance impacts as tenant usage patterns diverge.
FAQs
Does autoscaling cause a connection drop?
No. Active connections remain open throughout normal autoscaling events. Your database stays responsive, and applications remain unaware of the scaling process.
What happens if I use scale-to-zero and try to connect to a suspended database?
Lakebase automatically wakes the compute layer on the next connection attempt. Reactivation is transparent to your application and typically completes within milliseconds. Standard PostgreSQL client timeouts accommodate this reactivation window.
Can I control the autoscaling range?
Yes. You configure a minimum and maximum compute capacity. Autoscaling stays within that range based on demand. You can adjust these bounds anytime to balance cost and performance.
Does autoscaling require schema or application changes?
No. Autoscaling is transparent to your application code. Existing applications work unchanged. If you use scale-to-zero, consider adding connection retry logic as a defensive best practice for development or staging environments.
How quickly does scaling happen?
Autoscaling monitoring and decision-making occur continuously. Scaling adjustments typically complete within a few hundred milliseconds, well below the threshold where most applications notice latency.
The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.