Modelling Postgres Performance Degradation on Burstable Cloud Instances | POSETTE 2026

Learn how to model the exact saturation point of a throttled Postgres instance. Chun Lin Goh (.NET Foundation Member) explores this in his talk “Modelling Postgres Performance Degradation on Burstable Cloud Instances” at POSETTE: An Event for Postgres 2026. Abstract: Many developers run Postgres on "burstable" cloud instances (like Azure B-series or AWS T-series) to optimise costs. While cost-effective, these instances operate on a CPU credit model that introduces non-linear performance risks. The danger is not a system crash, but throughput exhaustion. When CPU credits are depleted, the cloud provider throttles the CPU to its base frequency. Because Postgres is unaware of this external throttling, it continues to accept connections it can no longer process in a timely manner. This leads to a cascading failure, i.e. connection pools saturate, p99 latencies skyrocket, and the app layer eventually times out. The database will effectively be unavailable despite being "online." In this session, I will demonstrate how to model the exact saturation point of a throttled Postgres instance. I will show you a simple simulation method to calculate your "Base Performance Ceiling" without the need for expensive load-testing infrastructure, allowing you to right-size your database before the credits run out. Chun Lin Goh is a software engineer based in Singapore specializing in Cloud Architecture and Observability. Since 2019, he has been a proud member of the .NET Foundation, contributing to the ecosystem through open source (Orchard Core) and speaking engagements (including .NET Conf 2024). Chun Lin helps engineers bridge the gap between infrastructure metrics and application performance. His passion lies in using simulation and mathematics to solve complex scaling problems before they hit production. ► Video chapters: ⏩ 00:00 – Music & introduction ⏩ 01:51 – How CPU credits and bursting work ⏩ 03:48 – Token bucket explained simply ⏩ 05:43 – The hidden risk: CPU credit dep