Symfony Doctrine Messenger

Symfony’s Doctrine Messenger bridge implements a Doctrine DBAL-backed transport for the Symfony Messenger component, letting any supported relational database act as a message queue with no additional broker to run. It’s a common choice for small-to-medium applications that want reliable async messaging without standing up RabbitMQ or another dedicated broker.

The transport handles message storage, delivery, redelivery, and failure handling directly through Doctrine DBAL, and includes a PostgreSQL-specific listener that uses LISTEN/NOTIFY to reduce polling latency for near-real-time message pickup.

What You Get

• A doctrine:// transport DSN that plugs directly into Symfony Messenger’s routing configuration
• Connection, DoctrineSender, and DoctrineReceiver classes implementing queue semantics over Doctrine DBAL
• Automatic table creation/management for the underlying message queue table
• PostgreSQL LISTEN/NOTIFY support via PostgreSqlNotifyOnIdleListener for lower-latency delivery than polling alone
• Standard Messenger failure/retry handling backed by the same database transport

Common Use Cases

• Adding async message processing to a Symfony app without provisioning a separate message broker
• Running background jobs (emails, exports, notifications) queued through the app’s existing database
• Building a low-traffic or early-stage SaaS where a Redis/RabbitMQ broker would be operational overkill
• Getting near-real-time message delivery on PostgreSQL via LISTEN/NOTIFY instead of tight polling loops
• Prototyping Messenger-based architectures locally before migrating to a dedicated broker in production

Under The Hood

Architecture The bridge is small and single-purpose: Transport/Connection.php owns the raw Doctrine DBAL interaction (table creation, insert, select-for-update-style dequeue, ack/reject), DoctrineTransport.php implements Messenger’s TransportInterface and delegates to DoctrineSender/DoctrineReceiver for the send/receive halves, and DoctrineTransportFactory.php parses the doctrine:// DSN to build a configured transport. PostgreSqlConnection.php and EventListener/PostgreSqlNotifyOnIdleListener.php extend the base connection with Postgres-specific LISTEN/NOTIFY behavior. Tech Stack Requires PHP 8.4.1+ and doctrine/dbal ^4.3, plus symfony/messenger ^8.1 and symfony/event-dispatcher; it’s a thin bridge package with almost no dependencies beyond Doctrine and core Symfony contracts. Code Quality The Tests/ directory covers Connection, both transport factories, and the PostgreSQL notify listener with dedicated PHPUnit test classes; as an official Symfony component it inherits the framework’s shared CI, coding-standard, and BC-policy enforcement. API Design Configuration is entirely DSN-driven (doctrine://default?queue_name=async), so adopting it requires no new PHP interfaces to learn beyond what Messenger already exposes — the transport is a drop-in replacement for AMQP/Redis transports behind the same TransportInterface contract.