# Bohan Zhang - Scaling PostgreSQL to power 800 million ChatGPT users (Highlights)  ## Metadata **Review**:: [readwise.io](https://readwise.io/bookreview/61818934) **Source**:: #from/readwise #from/reader **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[Bohan Zhang]] **Full Title**:: Scaling PostgreSQL to power 800 million ChatGPT users **Category**:: #articles #readwise/articles **Category Icon**:: 📰 **Document Tags**:: #work **URL**:: [openai.com](https://openai.com/index/scaling-postgresql/) **Host**:: [[openai.com]] **Highlighted**:: [[2026-07-03]] **Created**:: [[2026-07-04]] ## Highlights - To mitigate these limitations and reduce write pressure, we’ve migrated, and continue to migrate, shardable (i.e. workloads that can be horizontally partitioned), write-heavy workloads to sharded systems such as Azure Cosmos DB, optimizing application logic to minimize unnecessary writes. ([View Highlight](https://read.readwise.io/read/01kwktgn0e9zrndatacrsw8hgs)) ^1031052183 - In addition, when backfilling table fields, we enforce strict rate limits to prevent excessive write pressure. ([View Highlight](https://read.readwise.io/read/01kwktm9xvfecrb7cfqj16mx2b)) ^1031052284 - If joins are necessary, we learned to consider breaking down the query and move complex join logic to the application layer instead. ([View Highlight](https://read.readwise.io/read/01kwktr452v6edmrjky227k01m)) ^1031052367 - Configuring timeouts like idle_in_transaction_session_timeout is essential to prevent them from blocking autovacuum. ([View Highlight](https://read.readwise.io/read/01kwktrm6qd45jt16hg4v8sxtq)) ^1031052378 - Solution: To mitigate the “noisy neighbor” problem, we isolate workloads onto dedicated instances to ensure that sudden spikes in resource-intensive requests don’t impact other traffic. Specifically, we split requests into low-priority and high-priority tiers and route them to separate instances ([View Highlight](https://read.readwise.io/read/01kwktvkvhvrgat2skf1w0y2wt)) ^1031052445 #takeaway - We deployed PgBouncer as a proxy layer to pool database connections. Running it in statement or transaction pooling mode allows us to efficiently reuse connections, greatly reducing the number of active client connections. ([View Highlight](https://read.readwise.io/read/01kwktxwrp444026r918k4m06r)) ^1031052492 - To prevent overload during cache-miss storms, we implement a cache locking (and leasing) mechanism so that only a single reader that misses on a particular key fetches the data from PostgreSQL. When multiple requests miss on the same cache key, only one request acquires the lock and proceeds to retrieve the data and repopulate the cache. ([View Highlight](https://read.readwise.io/read/01kwkv07b165tz67wvrn82ejj1)) ^1031052546 - We implemented rate-limiting across multiple layers—application, connection pooler, proxy, and query—to prevent sudden traffic spikes from overwhelming database instances and triggering cascading failures. ([View Highlight](https://read.readwise.io/read/01kwkv2kpvf7cgbmt3b6sre6f3)) ^1031052616 - We enforce a strict 5-second timeout on schema changes. ([View Highlight](https://read.readwise.io/read/01kwkv40te77kehc4gj72vkjn2)) ^1031052649