Can my DB?

-- Subscriber session
LISTEN orders_channel;
-- Client waits for notifications asynchronously

-- Publisher session (e.g., from a trigger or application)
NOTIFY orders_channel, 'order_id=42';

-- From within a trigger or function
CREATE FUNCTION notify_on_order()
RETURNS trigger LANGUAGE plpgsql AS $$
BEGIN
  PERFORM pg_notify('orders_channel',
    json_build_object('id', NEW.id, 'total', NEW.total)::text);
  RETURN NEW;
END;
$$;

CREATE TRIGGER trg_notify_order
AFTER INSERT ON orders
FOR EACH ROW EXECUTE FUNCTION notify_on_order();

-- Unsubscribe
UNLISTEN orders_channel;

• Notifications fire only if the sending transaction commits, and every listening session on that channel receives each one.
• Payload is a text string, max 8000 bytes.
• Use pg_notify(channel, payload) from triggers or PL/pgSQL; plain NOTIFY takes a literal channel name.
• Client drivers (libpq, psycopg, pgx, node-postgres) expose async callbacks. Delivery is best-effort: disconnected clients miss events.

• No in-database pub/sub. Typical substitutes: a polled notifications table, Redis or RabbitMQ, or Debezium CDC on the binlog.
• UDFs can call out to external services but are not a messaging primitive.

• Same story as MySQL: no in-database pub/sub, same substitutes. MaxScale can route binlog/CDC events at the proxy layer.

-- Publisher: signal an alert
DBMS_ALERT.SIGNAL('orders_alert', 'order_id=42');
COMMIT;  -- Alert is sent on COMMIT

-- Subscriber: wait for the alert
DECLARE
  l_message VARCHAR2(1800);
  l_status  INTEGER;
BEGIN
  DBMS_ALERT.REGISTER('orders_alert');
  DBMS_ALERT.WAITONE('orders_alert', l_message, l_status, 30);
  IF l_status = 0 THEN
    DBMS_OUTPUT.PUT_LINE('Received: ' || l_message);
  END IF;
END;
/

• DBMS_ALERT is the direct LISTEN / NOTIFY analog: named alerts, commit-synchronized, fan-out to every registered session.
• DBMS_PIPE is a synchronous session-to-session pipe, not pub/sub.
• Oracle Advanced Queuing (AQ) is a full persistent messaging system in the database when durability matters.

-- Service Broker: async messaging
CREATE MESSAGE TYPE OrderNotification VALIDATION = NONE;
CREATE CONTRACT OrderContract (OrderNotification SENT BY INITIATOR);
CREATE QUEUE OrderQueue;
CREATE SERVICE OrderService ON QUEUE OrderQueue (OrderContract);

-- Send a message
DECLARE @handle UNIQUEIDENTIFIER;
BEGIN DIALOG @handle FROM SERVICE OrderService TO SERVICE 'OrderService'
  ON CONTRACT OrderContract WITH ENCRYPTION = OFF;
SEND ON CONVERSATION @handle MESSAGE TYPE OrderNotification (N'order_id=42');
END CONVERSATION @handle;

-- Receive a message
RECEIVE TOP(1) message_body FROM OrderQueue;

• Service Broker is a persistent, reliable in-database message queue: messages survive restarts, which LISTEN / NOTIFY does not.
• The cost of that durability is far more ceremony than LISTEN / NOTIFY: message types, contracts, queues, services, and dialogs.
• Query Notifications (SqlDependency in ADO.NET) fire on result-set changes and sit closer to LISTEN / NOTIFY for data-change use cases.

• No pub/sub in SQL. The update_hook and commit_hook C callbacks notify the same process; cross-process messaging is the host application's problem.

• No in-database pub/sub. Cluster-level events (query completion, etc.) can be routed through EventBridge; application pub/sub belongs on SNS, SQS, or Kinesis.

• No in-database pub/sub. IBM MQ is the messaging option alongside DB2; Event Publishing and Q Replication cover CDC-style change feeds.

• No LISTEN / NOTIFY. For data-change events, pair Streams (per-table CDC) with Tasks (scheduled or stream-driven).
• External functions can call webhooks to push events out to other systems.

• No in-database pub/sub. Cloud Pub/Sub, Dataflow, and scheduled queries are the common pieces for change propagation.