--- title: Autoscaling Lakebase Postgres | daily.dev description: Neon explains how Lakebase Postgres autoscales compute in real time by separating storage and compute layers, so VMs can resize without moving data. The... canonical: https://daily.dev/posts/autoscaling-lakebase-postgres-swlrwupfc twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Autoscaling Lakebase Postgres | daily.dev og:description: Neon explains how Lakebase Postgres autoscales compute in real time by separating storage and compute layers, so VMs can resize without moving data. The... og:url: https://daily.dev/posts/autoscaling-lakebase-postgres-swlrwupfc og:image: https://api.daily.dev/og/posts/sWlRWUpfc.png og:image:alt: Autoscaling Lakebase Postgres og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Autoscaling Lakebase Postgres **[Neon](https://daily.dev/sources/neontech)** · 12 min read · 0 upvotes · 0 comments ## Summary Neon explains how Lakebase Postgres autoscales compute in real time by separating storage and compute layers, so VMs can resize without moving data. The autoscaling algorithm tracks three signals - CPU load, memory use, and a time-aware HyperLogLog-based estimate of the Postgres working set (compute cache size) - polled at different frequencies (100ms, 5s, 20s). Resizing is coordinated by an autoscaler-agent, vm-monitor, a modified Kubernetes scheduler, and NeonVM (built on QEMU/KVM), allowing live resizing or migration of VMs without dropping connections. The average production database on Neon changes compute size roughly 32,000 times per month. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How does Neon's Lakebase Postgres decide when to scale compute up or down? It tracks three signals and takes the largest resulting target size, constrained by user-configured limits: CPU load (keeping one-minute average load at or below 90%), memory use (keeping usage below 75% of allocated RAM, checked every 100ms by a vm-monitor and every 5s by an autoscaler-agent), and a compute-cache working-set estimate computed every 20 seconds using a time-aware HyperLogLog across windows from one to 60 minutes. _Teams evaluating autoscaling strategies for Postgres can track architecture deep dives like this on daily.dev._ ### How does Lakebase Postgres resize a running Postgres VM without downtime? Four coordinating components handle it: the autoscaler-agent computes target sizes, a modified Kubernetes scheduler approves upscales to prevent overcommitting memory, NeonVM (built with QEMU and KVM) adds or removes CPU and memory from the live VM, and the vm-monitor expands or shrinks the compute cache accordingly. If a node lacks room, NeonVM can live-migrate the VM while keeping its IP address so connections stay open. _Engineers weighing VM-based versus container-based scaling architectures can follow this kind of infrastructure detail on daily.dev._ ### Why is a standard HyperLogLog not enough to estimate a database's working set for autoscaling? A standard HyperLogLog only grows and cannot tell when an item was last seen, so it answers how many distinct pages were accessed since startup rather than how many belong to the workload running now. Lakebase Postgres modifies HyperLogLog registers to store timestamps instead of bits, letting it estimate cardinality over any recent time window ending at the present, from one minute up to 60 minutes. _Developers curious about applying probabilistic data structures to real systems can find deep dives like this on daily.dev._ --- Tags: [#kubernetes](https://daily.dev/tags/kubernetes), [#postgresql](https://daily.dev/tags/postgresql) [View this post on daily.dev](https://daily.dev/posts/autoscaling-lakebase-postgres-swlrwupfc) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Autoscaling Lakebase Postgres","url":"https://daily.dev/posts/autoscaling-lakebase-postgres-swlrwupfc","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/autoscaling-lakebase-postgres-swlrwupfc"},"datePublished":"2026-08-31T16:48:56.572Z","dateModified":"2026-08-31T17:59:48.371Z","description":"Neon explains how Lakebase Postgres autoscales compute in real time by separating storage and compute layers, so VMs can resize without moving data. The...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/76c57f056a100772abb51f7f2af17152?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/76c57f056a100772abb51f7f2af17152?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Neon","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Neon","logo":"https://media.daily.dev/image/upload/s--65EDghou--/f_auto/v1724339118/logos/neontech","url":"https://daily.dev/sources/neontech"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/autoscaling-lakebase-postgres-swlrwupfc","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"kubernetes,postgresql","timeRequired":"PT12M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Neon","item":"https://daily.dev/sources/neontech"},{"@type":"ListItem","position":3,"name":"Autoscaling Lakebase Postgres"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/autoscaling-lakebase-postgres-swlrwupfc#faq","mainEntity":[{"@type":"Question","name":"How does Neon's Lakebase Postgres decide when to scale compute up or down?","acceptedAnswer":{"@type":"Answer","text":"It tracks three signals and takes the largest resulting target size, constrained by user-configured limits: CPU load (keeping one-minute average load at or below 90%), memory use (keeping usage below 75% of allocated RAM, checked every 100ms by a vm-monitor and every 5s by an autoscaler-agent), and a compute-cache working-set estimate computed every 20 seconds using a time-aware HyperLogLog across windows from one to 60 minutes. Teams evaluating autoscaling strategies for Postgres can track architecture deep dives like this on daily.dev."}},{"@type":"Question","name":"How does Lakebase Postgres resize a running Postgres VM without downtime?","acceptedAnswer":{"@type":"Answer","text":"Four coordinating components handle it: the autoscaler-agent computes target sizes, a modified Kubernetes scheduler approves upscales to prevent overcommitting memory, NeonVM (built with QEMU and KVM) adds or removes CPU and memory from the live VM, and the vm-monitor expands or shrinks the compute cache accordingly. If a node lacks room, NeonVM can live-migrate the VM while keeping its IP address so connections stay open. Engineers weighing VM-based versus container-based scaling architectures can follow this kind of infrastructure detail on daily.dev."}},{"@type":"Question","name":"Why is a standard HyperLogLog not enough to estimate a database's working set for autoscaling?","acceptedAnswer":{"@type":"Answer","text":"A standard HyperLogLog only grows and cannot tell when an item was last seen, so it answers how many distinct pages were accessed since startup rather than how many belong to the workload running now. Lakebase Postgres modifies HyperLogLog registers to store timestamps instead of bits, letting it estimate cardinality over any recent time window ending at the present, from one minute up to 60 minutes. Developers curious about applying probabilistic data structures to real systems can find deep dives like this on daily.dev."}}]} ```