Product Decisions This Supports
- Storage-cost and data-hygiene roadmap items. An "orphan sweeper" that reclaims records/files left behind when rows are deleted outside Eloquent (raw SQL, bulk deletes, queue table truncation) directly supports any initiative around storage spend, retention policy, or database bloat. This is the kind of work that never wins a sprint on its own but shows up as a recurring line item in infra costs.
- Build vs. buy for cleanup plumbing. The package now handles both detection and scheduling, which is the part teams usually underestimate. Buying here avoids a bespoke Artisan command, a cron entry, and the operational documentation that goes with it — a small but real engineering trade.
- Compliance and deletion-guarantee features. "Deleted" meaning actually deleted matters for GDPR/DSAR workflows and data-retention commitments. The v1.1.2 documentation of raw-delete cleanup patterns is a supporting artifact for those conversations, not just developer convenience.
- Use-case fit: media libraries, attachment/file tables, soft-delete-plus-purge flows, and any codebase where migrations, seeders, or admin tooling issue
DELETE statements that bypass model events.
- Upgrade decision on v1.1.2 specifically: additive and low-risk — no breaking changes, no deprecations. The one behavior change worth a decision is that the sweeper is now auto-scheduled during install, which is an implicit side effect on deploy. Teams with strict change-control or existing custom schedules should confirm this is what they want before upgrading.
When to Consider This Package
Adopt when most of the following hold:
- You have Eloquent models with associated files or dependent rows, and deletes happen through more than one path (admin UI, jobs, raw SQL, migrations).
- Orphan accumulation is measurable — S3/storage bills, table growth, or support tickets about "ghost" records.
- You already run Laravel's scheduler, so a registered scheduled command is a natural fit.
- Your team is small enough that owning a homegrown sweeper has a real maintenance cost.
- You can accept eventual-consistency cleanup (sweep on a schedule) rather than synchronous, guaranteed-on-delete removal.
Look elsewhere when:
- Deletion must be immediate and transactional — a scheduled sweeper is the wrong shape; you want model events, foreign keys with cascades, or soft deletes with a hard-delete policy.
- You need an audited, certified retention tool for regulated data; a community package plus your own runbook is not that, though it can be a component.
- The system has a single, well-controlled delete path where a sweeper adds a scheduled job and a failure mode for no benefit.
- You can't tolerate destructive automation — the value proposition is bulk deletion, which demands dry-run, logging, and backups you may not have.
Note that v1.1.2 removed a deployment script from the project structure; this is housekeeping and does not affect adoption. The auto-scheduling behavior does affect it: installing the package now changes your schedule. Treat that as a deliberate configuration decision, not a default, and verify it in staging.
How to Pitch It (Stakeholders)
For executives: This is a small, low-risk maintenance package that reduces storage and database costs by cleaning up data left behind when records are deleted outside the normal application path. The latest release (v1.1.2) makes it self-configuring — it registers its own cleanup schedule on install, so there's no ongoing operational overhead — and adds documentation for the delete patterns that cause the waste. No breaking changes; upgrade risk is low. The main governance point is that it performs automated deletion, so we should confirm logging, dry-run, and backup coverage before enabling it in production.
For engineering: v1.1.2 is additive. The sweeper is auto-scheduled at install time, which removes the manual cron step but also means the package mutates your schedule implicitly — review the registration in staging and confirm it doesn't duplicate an existing job or fire at a bad window. The new docs cover raw-delete cleanup, which is the actual failure mode this package addresses: bulk DELETEs, truncations, and query-builder deletes that skip model events and strand files or child rows. The deployment script was dropped from the project structure; nothing to migrate. Before rollout, decide explicitly on: dry-run-first default, retention window, logging/alerting on sweep volume, and a restore path if a sweep removes something it shouldn't.