Assess PostgreSQL notifications at the writer commit boundary
LISTEN/NOTIFY design depends on writer contention and recovery, not just message volume. Separate bounded wake-ups from durable events and check version scope.
By 
Paul. Architecture and infrastructure
A notification mechanism can carry modest messages and still interfere with an application's write path. Assess PostgreSQL LISTEN/NOTIFY around concurrent writers and transaction commits, alongside notification volume. A bounded wake-up signal can remain useful when durable state lives elsewhere. Treating notifications as the only record of business events creates a different problem: recovering what happened when a consumer was absent.
Looking back from November 2026 requires separating several dates. Elliot Levin's Recall.ai report was published on 1 July 2025, describing incidents on 19–22 March 2025 and contention in a highly concurrent workload. The page now displays an 8 May 2026 update and credits a core change with eliminating the bottleneck. Those are the author's workload evidence and later update, not an AL+ benchmark or proof about every deployed PostgreSQL version.
The writer pays before the listener acts
The architectural question starts with the work attached to committing a business transaction. If many writers converge on shared notification machinery, a small notification payload does not by itself establish a small coordination cost. A message-volume estimate can miss that interaction. The relevant question is what concurrent writers must wait for before their own work can finish.
This changes how to interpret a quiet notification channel. The consumer may see little work while the writers still contend at a shared boundary. Conversely, a channel that delivers many useful signals does not establish that writers have become the bottleneck. These are different observations. Inspect the relationship between commit behavior and the application's actual concurrency before deciding which observation explains a slowdown.
For an illustrative ingestion service, a change in the number of simultaneous writers could matter even if the average number of notifications per second appeared acceptable. Bursts and transaction boundaries may expose a different operating condition from a steady single-writer exercise. This is a proposed investigation, not a test run here. It supplies no throughput threshold or capacity promise.
The business consequence is that a secondary convenience can become coupled to primary writes. A signal intended to wake a worker should be evaluated against the importance of the transaction carrying it. If delayed commits prevent the application from accepting essential updates, the notification path belongs in the reliability discussion. Calling it lightweight does not answer that dependency question.
Later discussion is evidence of discussion
Nikolay Samokhvalov's 10 July 2025 mailing-list message proposed documenting performance risks, including commit locking and duplicate checking. It is later evidence, outside the 2–8 July research period. A proposal hosted on the official mailing-list archive is evidence of what its author proposed; it is not automatically an accepted documentation change or a released fix.
Recall's updated page links a core optimization commit dated 15 January 2026. That link improves the specificity of the later claim, but a repository commit still needs to be mapped to the release and build actually installed. The commit description concerns avoiding unnecessary listener wake-ups and explicitly reports no improvement when every listener reads every message. It should not be read as independent proof of an unconditional writer-contention fix. This article does not establish a first fixed release or claim that an older incident reproduces on a current installation.
The practical consequence is a version-aware decision. Record the running version, relevant maintenance changes and the concurrency pattern that prompted concern. An old report can suggest what to inspect without supplying a current performance verdict. Equally, reading that an optimization exists is not enough to assume that every environment already contains it.
A wake-up needs durable work behind it
The PostgreSQL 18 NOTIFY documentation, read as versioned but mutable documentation in November 2026, describes delivery after transaction commit and possible folding of identical notifications within one transaction. The LISTEN documentation describes session registration and the startup race: commit the registration, inspect database state, then rely on subsequent notifications. These semantics matter independently of the historical contention report.
A useful wake-up says that a consumer should inspect durable state. In an illustrative job processor, the notification can prompt a worker to look for pending work, while stored records establish what remains to be done. Missing or combining a prompt need not lose a job if the recovery procedure independently discovers the pending record. That outcome depends on the application design; the notification does not create it automatically.
Define recovery before relying on that arrangement. After reconnecting, a worker needs a way to find outstanding work and avoid repeating effects incorrectly. A periodic reconciliation or another bounded check can reduce dependence on receiving every prompt. The exact mechanism should follow the product's delivery requirements and the cost of delayed processing.
A durable event stream serves a stronger contract. If consumers need replay, an ordered history or evidence that a particular event was processed, those obligations need persistent records and explicit progress tracking. A transient notification alone cannot establish that history. Changing the transport without defining acknowledgments and recovery would leave the central promise unresolved.
Keep the simpler mechanism when its limits fit
The strongest counterargument to replacing LISTEN/NOTIFY is the operational cost of another messaging system. A small application may already have PostgreSQL, bounded concurrency and a tolerable recovery interval. Adding a separate service can introduce more things to deploy and diagnose than the notification path currently requires. Simplicity is a legitimate reason to keep a mechanism whose limits match the task.
That argument supports bounded use, rather than unrestricted confidence. Describe the expected writer pattern, acceptable delay and the recovery path. If sustained per-write signaling is central to a highly concurrent service, representative contention checks become more important. If a signal merely shortens the wait before an independently recoverable check, the design has more room to tolerate missing prompts.
For custom software development, begin with the business event that must survive and the transaction that records it. Then choose how consumers learn to inspect it. Judge commit contention against the installed version and workload, and judge recovery against the durable promise. Those two decisions give notifications a clear role without extending one author's incident into a universal scaling rule.