CONCEPT Cited by 1 source
LISTEN/NOTIFY payload limit¶
Definition¶
Postgres's built-in LISTEN / NOTIFY pub/sub mechanism enforces an
8 KB payload limit on each NOTIFY message. Any application
wanting to fan out larger messages via this channel must chunk the
payload, reassemble it on the subscriber side, handle ordering, and
handle dropped chunks — "at which point you've built a worse TCP on
top of a notification system." (Source:
sources/2026-02-27-planetscale-video-conferencing-with-postgres.)
Mechanism¶
NOTIFY channel_name, 'payload' queues a notification on a named
channel; any session that has issued LISTEN channel_name receives
the payload asynchronously. Notifications are delivered at least
once while the listening session is connected and are dropped on
disconnect — there is no durable queue behind them.
The 8 KB limit is enforced by Postgres core (NAMEDATALEN-adjacent
constant, not a config parameter). It applies to the payload
string, not the channel name.
Why this matters¶
This limit is a hard upper bound that rules out LISTEN/NOTIFY for
any message larger than a modest JSON event. Examples:
- A video frame at 640×360, JPEG quality 0.65: 25–40 KB. Must be chunked into 4–5 notifications.
- A binary blob, a moderate-size HTML document, a compressed batch of events: likely 10–100 KB. Must be chunked.
- Small JSON events (
{"user_id": 42, "event": "typing"}): well under 8 KB, natively fit.
For larger messages, the architectural alternatives are:
- Use logical replication as pub/sub — no payload size limit other than the row / WAL record limit, and ordered durable delivery to a subscriber slot.
- Use a dedicated broker (Kafka, NATS, Redis pub/sub) designed for media-sized payloads.
- Store the large payload in a blob store and publish a
NOTIFYwith the pointer — trades payload size for a second round-trip.
Seen in¶
- sources/2026-02-27-planetscale-video-conferencing-with-postgres
— canonical wiki framing. Nick Van Wiggeren considered
LISTEN/NOTIFYas the first candidate for his Postgres video- chat hack and rejected it on the 8 KB limit: "The problem is an enforced 8KB payload limit. A video frame at 640x360 is 25-40KB. We'd have to chunk every frame into 4-5 separate notifications, reassemble them on the other end, handle ordering, handle dropped chunks — at which point you've built a worse TCP on top of a notification system. Audio frames would mostly fit under 8KB, so we could do a hybrid approach, but splitting the media pipeline across two different transport mechanisms is the kind of complexity I wasn't interested in." Canonical rejection reasoning — the audio-sometimes-fits-but-video-doesn't half-fit shape is itself a worked example of why the limit forces a uniform alternative (logical replication carries both audio and video through the same substrate without chunking).