Product Decisions This Supports
- Build vs. buy for background job infrastructure. This package answers a narrow but real question: can we run delayed/background work without adding Redis, RabbitMQ, or SQS to our stack? Its answer is "put the queue in the database you already run." That is a legitimate architecture choice for teams whose operational budget is the binding constraint, and the decision it unlocks is "reuse existing Doctrine/MySQL ops instead of procuring and staffing a broker."
- Infrastructure consolidation roadmap. If the roadmap item is "reduce number of stateful services we operate," a DB-backed queue driver is a candidate to evaluate alongside broker-based options. This package is a data point in that comparison, not the winner.
- Legacy Symfony estate triage. For an existing Symfony 3.x/4.x application already using
mcfedr/queue-manager-bundle, this is a decision about patching vs. migrating: keep the working queue, or fold it into a Symfony Messenger migration. It informs sequencing and risk on a modernization epic.
- Scope calibration on "job queue" feature work. Product asks for scheduled emails, webhook retries, report generation, or export jobs. The decision here is whether that feature ships as (a) cron + a status column, (b) this package, or (c) Symfony Messenger with a Doctrine transport. This package sits between (a) and (c) — it gives you retries and delays without new services, but brings unmaintained code.
- Not a Laravel decision. Flag clearly: this is a Symfony bundle, not a Laravel package. It does not plug into Laravel's queue contract,
Horizon, or queue:work. Any Laravel-side evaluation should stop here; the equivalent decision in Laravel is database queue driver (core) or laravel/horizon for Redis. Do not let the "PHP package" label put this on a Laravel shortlist.
When to Consider This Package
Adopt-adjacent criteria (narrow):
- You are on Symfony 3.x/4.x, already depend on
mcfedr/queue-manager-bundle, and this bundle is the wiring layer for the Doctrine delay driver.
- You cannot add infrastructure — no broker allowed by security/ops, or the workload is small enough (hundreds to low thousands of jobs/day) that a DB table is genuinely sufficient.
- Your jobs are delay-tolerant (minutes to hours, not sub-second), and polling latency is acceptable to the product.
- Your team is willing to vendor/fork the driver and own it. With 2 stars, 0 dependents, and a last release of 2018-04-17, the maintenance signal is unambiguous: treat this as source code you are adopting, not a dependency you are consuming.
Look elsewhere when:
- Laravel. Any Laravel app — use the built-in
database or redis queue driver. This package is structurally irrelevant.
- Symfony 5.4+/6+/7+ or PHP 8.x. Seven-plus years without a release means it predates Doctrine DBAL 3/4, modern Symfony DI signatures, and PHP 8 typing. Expect incompatibility, not just staleness.
- Throughput or concurrency matters. DB polling queues contend with your OLTP workload — row locks,
SELECT ... FOR UPDATE hotspots, and table growth on the same database serving user traffic.
- You need observability. No dashboard, no metrics, no failed-job UI. If product needs "how many jobs failed and why," budget for building that yourself.
- Security/compliance review applies. Unmaintained transitive dependencies with no CVE response path is a finding in most audits. Mitigate only via fork.
- Symfony Messenger is available. For virtually every greenfield case, Messenger + Doctrine transport covers this use case with active maintenance, retries, failure transport, and a first-party upgrade path. This is the default recommendation.
How to Pitch It (Stakeholders)
One line for executives: "A small, MIT-licensed Symfony add-on that lets background jobs run out of our existing database instead of a new message broker — cheap operationally, but unmaintained since 2018, so we'd be adopting code rather than a supported product."
The trade: We avoid provisioning and staffing a broker (real, recurring ops cost) in exchange for owning code nobody else maintains (real, recurring engineering cost). The trade is only favorable for a legacy Symfony app with modest job volume and a hard constraint against new services. Everywhere else, Symfony Messenger's Doctrine transport delivers the same "no new infrastructure" benefit with an active maintainer, failure handling, and an upgrade path — same architectural idea, supported implementation.
Recommendation: Treat this package as a pattern reference, not a dependency. Do not add it to a new build; do not put it on a Laravel evaluation list (it's a Symfony bundle and won't integrate). If we have a live Symfony 3/4 app already using it, the decision is "fork it and pin it" versus "fund the Messenger migration" — and I'd argue for funding the migration, since the fork's total cost of ownership (security patching, DBAL compatibility, PHP 8 upgrades) exceeds the migration's one-time cost within roughly two release cycles.
Ask: One spike (2–3 days) to confirm current Doctrine/PHP compatibility and estimate the Messenger migration, so we can close this question with data instead of re-litigating it.