--- title: LISTEN Carefully: How NOTIFY Can Trip Up Your Database description: PostgreSQL's LISTEN/NOTIFY mechanism can silently cause severe performance bottlenecks in high-throughput databases. A real production incident is examined... canonical: https://daily.dev/posts/listen-carefully-how-notify-can-trip-up-your-database-vkypsjscr twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: LISTEN Carefully: How NOTIFY Can Trip Up Your Database | daily.dev og:description: PostgreSQL's LISTEN/NOTIFY mechanism can silently cause severe performance bottlenecks in high-throughput databases. A real production incident is examined... og:url: https://daily.dev/posts/listen-carefully-how-notify-can-trip-up-your-database-vkypsjscr og:image: https://api.daily.dev/og/posts/VKYpsjsCR.png og:image:alt: LISTEN Carefully: How NOTIFY Can Trip Up Your Database og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # LISTEN Carefully: How NOTIFY Can Trip Up Your Database **[Planet PostgreSQL](https://daily.dev/sources/planet-postgresql)** · 2 min read · 3 upvotes · 0 comments ## Summary PostgreSQL's LISTEN/NOTIFY mechanism can silently cause severe performance bottlenecks in high-throughput databases. A real production incident is examined where NOTIFY triggered AccessExclusive lock cascades on pg_database, effectively halting a busy database. The fix involves moving NOTIFY off the transaction hot path using unlogged queue tables, transaction-level advisory locks (pg_try_advisory_xact_lock), and batching strategies. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why does PostgreSQL NOTIFY cause AccessExclusive locks on pg_database in a high-throughput system? NOTIFY's internal serialisation mechanism can trigger AccessExclusive lock cascades on pg_database, which can bring a busy production database to a near halt under heavy notification load. This happens because of how PostgreSQL internally coordinates and serializes notification delivery across backends, turning what looks like lightweight async messaging into a serious contention point. _Engineers debugging mysterious lock contention around LISTEN/NOTIFY can find real incident writeups like this through daily.dev._ ### How can I avoid NOTIFY becoming a bottleneck in a busy PostgreSQL database? Move NOTIFY out of the transaction hot path by architecting around it with unlogged queue tables, transaction-level advisory locks such as pg_try_advisory_xact_lock, and batching notifications instead of firing them synchronously within every transaction. This decouples the notification workload from the critical path that handles high-throughput writes. _Teams architecting resilient PostgreSQL notification pipelines can track practical fixes like this on daily.dev._ ## Similar posts on daily.dev - [Postgres LISTEN/NOTIFY actually scales](https://daily.dev/posts/postgres-listen-notify-actually-scales-wehhixojn) · Hacker News · 34 upvotes · 2 comments --- Tags: [#database](https://daily.dev/tags/database), [#postgresql](https://daily.dev/tags/postgresql) [View this post on daily.dev](https://daily.dev/posts/listen-carefully-how-notify-can-trip-up-your-database-vkypsjscr) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"LISTEN Carefully: How NOTIFY Can Trip Up Your Database","url":"https://daily.dev/posts/listen-carefully-how-notify-can-trip-up-your-database-vkypsjscr","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/listen-carefully-how-notify-can-trip-up-your-database-vkypsjscr"},"datePublished":"2026-07-15T16:51:10.622Z","dateModified":"2026-09-14T07:37:47.045Z","description":"PostgreSQL's LISTEN/NOTIFY mechanism can silently cause severe performance bottlenecks in high-throughput databases. A real production incident is examined...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/d37317747e2409cf40042cd64deb8b46?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/d37317747e2409cf40042cd64deb8b46?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Planet PostgreSQL","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Planet PostgreSQL","logo":"https://media.daily.dev/image/upload/logos/placeholder.jpg","url":"https://daily.dev/sources/planet-postgresql"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/listen-carefully-how-notify-can-trip-up-your-database-vkypsjscr","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":3},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"database,postgresql","timeRequired":"PT2M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Planet PostgreSQL","item":"https://daily.dev/sources/planet-postgresql"},{"@type":"ListItem","position":3,"name":"LISTEN Carefully: How NOTIFY Can Trip Up Your Database"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/listen-carefully-how-notify-can-trip-up-your-database-vkypsjscr#faq","mainEntity":[{"@type":"Question","name":"Why does PostgreSQL NOTIFY cause AccessExclusive locks on pg_database in a high-throughput system?","acceptedAnswer":{"@type":"Answer","text":"NOTIFY's internal serialisation mechanism can trigger AccessExclusive lock cascades on pg_database, which can bring a busy production database to a near halt under heavy notification load. This happens because of how PostgreSQL internally coordinates and serializes notification delivery across backends, turning what looks like lightweight async messaging into a serious contention point. Engineers debugging mysterious lock contention around LISTEN/NOTIFY can find real incident writeups like this through daily.dev."}},{"@type":"Question","name":"How can I avoid NOTIFY becoming a bottleneck in a busy PostgreSQL database?","acceptedAnswer":{"@type":"Answer","text":"Move NOTIFY out of the transaction hot path by architecting around it with unlogged queue tables, transaction-level advisory locks such as pg_try_advisory_xact_lock, and batching notifications instead of firing them synchronously within every transaction. This decouples the notification workload from the critical path that handles high-throughput writes. Teams architecting resilient PostgreSQL notification pipelines can track practical fixes like this on daily.dev."}}]} ```