---
title: "Autoscaling Lakebase Postgres"
description: "Lakebase Postgres addresses the waste and uncertainty of choosing a fixed database instance size before workload demand is known. Its decoupled architecture separates stateless compute from durable storage, allowing compute to start, stop, move, or resize without moving the database. The autoscaling algorithm combines CPU load, memory pressure, and a time-aware estimate of the Postgres working set, using modified HyperLogLog registers that store timestamps and estimate windows from one to 60 minutes. Scaling occurs live through autoscaler-agent, vm-monitor, Kubernetes scheduling, and NeonVM, with checks preventing unsafe downscales and scheduler approval for upscales. The system scales in both directions without dropping connections and operates across 100-millisecond, five-second, and 20-second timescales, including more than 32,000 resizes per month."
---

# Autoscaling Lakebase Postgres

[Databricks](https://yomu.fyi/company/databricks) · Carlota Soto · Aug 31, 2026

**Type:** Explainer

## Summary

Lakebase Postgres addresses the waste and uncertainty of choosing a fixed database instance size before workload demand is known. Its decoupled architecture separates stateless compute from durable storage, allowing compute to start, stop, move, or resize without moving the database. The autoscaling algorithm combines CPU load, memory pressure, and a time-aware estimate of the Postgres working set, using modified HyperLogLog registers that store timestamps and estimate windows from one to 60 minutes. Scaling occurs live through autoscaler-agent, vm-monitor, Kubernetes scheduling, and NeonVM, with checks preventing unsafe downscales and scheduler approval for upscales. The system scales in both directions without dropping connections and operates across 100-millisecond, five-second, and 20-second timescales, including more than 32,000 resizes per month.

## Context

Choosing a database instance size before the workload is known can waste compute. CPU-only autoscaling can also miss cache-bound workloads, where queries wait for network-fetched pages despite low CPU usage.

## Approach / What changed

Lakebase Postgres separates compute from durable storage and combines CPU, memory, and working-set signals to determine capacity. Modified timestamp-aware HyperLogLog estimates support multiple working-set windows, while autoscaler-agent, vm-monitor, Kubernetes scheduling, and NeonVM coordinate live resizing.

## Takeaways

- Compute nodes own no durable state, so they can be resized or live-migrated without moving the underlying database or dropping existing connections.
- The working-set estimator modifies HyperLogLog by storing update timestamps, allowing distinct-page estimates for windows from one minute through 60 minutes.
- Upscaling requires Kubernetes scheduler approval, while vm-monitor validates downscales to ensure Postgres and the guest still have enough memory.

**Tags:** [Architecture](https://yomu.fyi/topic/architecture), [Autoscaling](https://yomu.fyi/topic/autoscaling), [Kubernetes](https://yomu.fyi/topic/kubernetes), [Postgres](https://yomu.fyi/topic/postgres)

- Source: [Databricks](https://www.databricks.com/blog/autoscaling-lakebase-postgres)
- Source URL: https://www.databricks.com/blog/autoscaling-lakebase-postgres
- Ingested by Yomu: 2026-08-31T20:00:53.198Z

[Read original post](https://www.databricks.com/blog/autoscaling-lakebase-postgres)