Swiftmailerdatabasebundle Laravel Package

Product Decisions This Supports

• Build vs. buy for outbound email reliability. This package is a reference implementation of a database spool/outbox for mail, not a viable dependency. It informs the decision on whether to build a durable send path or lean on framework primitives (Laravel queues + Mail, Symfony Messenger + Mailer) — the answer is almost always the primitives.
• Roadmap input for a reliability/observability epic. The underlying requirements are real and worth a ticket: no lost transactional emails, bounded retries with backoff, per-message status/attempts/last_error, proof-of-send for support and compliance.
• Prioritizing email use cases by blast radius. Password resets, receipts/invoices, and account notifications justify durable spooling; marketing blasts usually belong to an ESP with webhooks and suppression lists, not an app-level DB spool.
• Triage/architecture hygiene. A concrete example to point at when someone proposes "let's add a bundle/gem for X": the decision framework should surface maintenance status, framework fit, and whether the platform already solves it.
• Correcting a framing error before it spreads. Note that despite the "Laravel/PHP package" label, this is a Symfony bundle tied to SwiftMailer (EOL Nov 2021, superseded by Symfony Mailer). It is not usable in a Laravel application — Laravel's Mail component plus the database queue driver already provides the equivalent, maintained behavior.

When to Consider This Package

Consider it only as a case study, or in the narrow legacy scenario:

• You maintain a Symfony 2.x/3.x/4.x app still on SwiftMailer, and you need sends to survive process restarts and leave an audit trail.
• You want to see a minimal, readable schema for a mail spool table before designing your own.

Look elsewhere — or build on framework primitives — when:

• You're on Laravel. Wrong framework, wrong mailer. Use Mail::queue() with the database or redis queue driver and a failed_jobs retry path.
• You're on modern Symfony. SwiftMailer is EOL; move to Symfony Mailer + Messenger transport, which is the maintained equivalent.
• You need deliverability features — bounces, complaints, suppression lists, DKIM/SPF alignment, per-domain throttling, templating/analytics. That's an ESP (SES, Postmark, SendGrid), not an spool table.
• You need horizontal scale. A single DB spool table with row locking becomes a contention point; a real queue (Redis/SQS) or an ESP handles fan-out better.
• You care about supply-chain risk. Zero stars, zero dependents, no release cadence, no guarantee of PHP 8.2+ compatibility or security patches. Adopting it means owning a fork.

Verdict: do not adopt as a dependency. Mine it for the pattern, then delete it.

How to Pitch It (Stakeholders)

To executives: We evaluated jarjobs/swiftmailerdatabasebundle for email reliability. It's an abandoned Symfony plugin built for SwiftMailer, which reached end-of-life in 2021 — no maintenance, no users, no security posture. We should not depend on it. However, it highlights a legitimate requirement: transactional emails currently have no durable retry or audit trail. I recommend a small, framework-native ticket (days, not weeks) to queue outbound mail through our existing job infrastructure, giving us retries, an audit record of every send, and support-visible status — with no new vendor dependency.

To engineering: Don't add the bundle. Implement the pattern directly: write the message to a mail_outbox table (recipient, template, payload, idempotency key, status, attempts, last_error, sent_at), dispatch a queued job to send it, let the existing failed-job/retry machinery handle backoff, and add a scheduled sweep for stuck rows. On Laravel this is Mail::queue() + the database queue driver; on Symfony it's Messenger + Mailer. We get observability, deduplication, and compliance evidence for the cost of one table and one job class.

To the requesting team: If the ask was "we need emails to not get lost," the requirement is valid and we'll fund it. If the ask was "adopt this package," the answer is no — it's unmaintained, framework-mismatched, and superseded by first-party tooling.