Postgres LISTEN/NOTIFY can scale to 60K writes/second despite global lock concerns

Challenging LISTEN/NOTIFY Scalability Myths

Postgres LISTEN/NOTIFY has historically been viewed as unscalable due to a global lock that causes unintuitive performance characteristics. This perception has led many to avoid using it for high-throughput applications. However, new findings indicate that these limitations are not inherent and can be overcome through optimization.

Achieving High Throughput with Optimization

Through specific optimizations, LISTEN/NOTIFY-backed streams were able to achieve 60,000 writes per second on a single Postgres server, maintaining millisecond-scale latency. This performance significantly surpasses the 2,900 writes per second observed in an initial, unoptimized implementation, which bottlenecked without visible resource consumption.

LISTEN/NOTIFY for Low-Latency Streaming

LISTEN/NOTIFY is a powerful tool for low-latency durable notifications, streams, and pub/sub within Postgres. It allows readers to block and wait for notifications, waking up immediately when new data arrives, which is more efficient than continuous polling. This mechanism is particularly useful for applications requiring real-time updates, such as LLM response token streaming.

Understanding the Global Lock

The core of the scalability challenge lies in a global lock that Postgres takes during NOTIFY operations. While this lock creates performance bottlenecks in unoptimized setups, understanding its behavior is key to developing strategies that mitigate its impact and allow LISTEN/NOTIFY to scale effectively for demanding applications.