Choosing a fixed database size before you know the workload is an old pattern. Lakebase Postgres removes that sizing exercise by continuously adjusting compute to match demand, while keeping PostgreSQL running and the data safely decoupled in the storage layer.
Key highlights
- Separate compute from durable storage: Lakebase runs PostgreSQL on stateless compute while safekeepers, pageservers, and object storage preserve WAL, page versions, and history. Because compute owns no durable data, it can be resized, moved, restarted, or replaced without moving the database underneath it.
- Use three signals, not CPU alone: The autoscaling algorithm tracks CPU load, memory use, and the frequently accessed working set. The final target is the largest of those goals, helping Lakebase respond not only to processor pressure but also to memory constraints and cache misses. See the autoscaling documentation.
- Estimate the working set over time: A time-aware cardinality estimate helps distinguish the workload that is active now from an old burst that has already ended. This lets the system protect useful cache without keeping compute oversized indefinitely.
- Resize a live database: Autoscaler agents, VM monitors, the Kubernetes scheduler, and NeonVM coordinate to add or remove CPU and memory from a running VM. If a node cannot accommodate an upscale, the VM can move to another node while keeping its IP address and existing connections open.
- Scale down as deliberately as you scale up: Downscaling is checked against PostgreSQL and guest memory requirements before capacity is removed. Within the configured range, autoscaling adjusts compute without restarts or connection interruptions, reducing cost during quieter periods.
๐ Read the full story here
