How to safely issue LISTEN/NOTIFY commands with Aurora Serverless V2?

Context When using PostgreSQL’s LISTEN/NOTIFY for pub/sub messaging, the connection must maintain a persistent link to the primary database instance because notifications are not replicated to read replicas. In Aurora PostgreSQL, connection pooling or read endpoints can interfere with these commands, causing missed events. Aurora Serverless V2 adds automatic scaling and connection management, so it’s important to understand how connection endpoints behave in this setup. Answer It is safe to issue LISTEN/NOTIFY commands using the same database connection string ( DATABASE_URL ) only if that connection points to the cluster endpoint, not the reader or pooled endpoint. The cluster endpoint in Aurora PostgreSQL always routes to the primary instance, ensuring that LISTEN/NOTIFY works as expected. The reader endpoint can route connections to any read replica, which does not receive notifications. Similarly, connections made through pooled endpoints (like PgBouncer in transaction pooling mode) don’t work with LISTEN/NOTIFY because they don’t keep the same session active between queries. Therefore, if the current db-secret module exposes a DATABASE_URL pointing to the cluster endpoint, you can safely use it for pub/sub connections. If it points to a reader or pooled endpoint, you’ll need to: Copy the cluster endpoint from your Aurora PostgreSQL cluster in the AWS Console. Expose it as a separate environment variable or secret. Configure your pub/sub client or process in your platform to use this new connection string. This ensures that all LISTEN/NOTIFY messages are published and received correctly in Aurora Serverless V2.