Laravel Prunekeeper Laravel Package

Product Decisions This Supports

• Build vs. buy for data retention: PruneKeeper covers the "archive-then-delete" pattern (compress old rows to a file, then remove them) that teams otherwise hand-roll per model. First stable release (v2.0.0) makes this a defensible dependency rather than a code you own and maintain.
• Compliance and data-retention roadmap: Ships zip, gzip, bzip2, and targz drivers, so archive format becomes a config value (prunekeeper.compression.driver or --compression) rather than an engineering task. That directly de-risks GDPR-style retention deadlines and storage-cost reduction initiatives.
• Scope decisions on soft deletes: Prunekeeper::makePrunableQuery() lets soft-deleted rows be included in pruning scope. This decides whether "recycle bin" features are safe to ship — previously you'd need custom query logic per model.
• Release/QA investment: Prunekeeper::flushState() for test isolation is a signal the package targets CI pipelines. Budget for test-suite updates when adopting, not for building test scaffolding.
• Operational risk posture: Exporters now clean up temp files on failure, which lowers disk-exhaustion risk in scheduled jobs. This is the kind of detail that decides whether a nightly prune job can run unattended on small volumes.
• Upgrade cost, if we piloted a pre-release: v2.0.0 is explicitly a breaking release — static methods instead of instances, and config callbacks now return void instead of $this. Any prototype built against pre-2.0 needs a rewrite of call sites and callbacks. Price that into the pilot decision rather than assuming a drop-in bump.

When to Consider This Package

Adopt when most of these hold:

• You have tables that grow unboundedly (logs, events, audit trails, notifications, sessions) and a policy that says "keep N days live, retain the rest as files."
• You are on a supported Laravel version and want a package that follows first-party conventions (static facades, config-driven drivers, artisan-style CLI flags) so it looks native to your engineers.
• You need a specific compression format for downstream consumers — bzip2 or targz for interchange with existing archive pipelines, not just zip.
• You need soft-delete-aware pruning rather than raw DELETE statements.
• You want prunes to be tested in CI without state bleeding between tests (flushState()).

Look elsewhere when:

• No real archival need: if you can simply delete or partition-drop old rows, a scheduled delete() or native table partitioning is less surface area.
• You need restore/import: the release describes export and prune only. If the requirement is "recover a deleted record," confirm this package covers it before committing — otherwise it's a one-way door by design.
• Long-term cold storage: there's no mention of S3/object-storage destinations or encryption. If retention means "years in S3 with encryption at rest," expect to build the upload/encryption layer around the exporters.
• Extension dependency is a problem: each driver needs a PHP extension (ext-zip, ext-zlib, ext-bz2, ext-phar). Shared hosting, minimal container images, or locked-down platform builds may not have them — verify before promising gzip/bzip2 in a roadmap.
• Single-maintainer risk is unacceptable: this is one author's package at its first stable release. If the data path is audit-critical, weigh maintenance risk and pin the version.

How to Pitch It (Stakeholders)

For executives: This is a small, free dependency that lets us delete old database records without losing them — they get compressed into archive files first. It reduces storage cost and gives us a repeatable answer to data-retention requirements, instead of an untested script per table. It reached its first stable release (v2.0.0), which is the point at which it becomes reasonable to depend on.

For engineering: v2.0.0 is the first production-ready cut. It follows Laravel first-party patterns (static API), gives us four compression drivers behind one config key, a soft-delete-aware query helper, flushState() for test isolation, and temp-file cleanup on exporter failure. Treat it as breaking from any pre-release — static methods and void-returning config callbacks require call-site and callback edits. Recommended path: pilot on one high-growth, low-risk table (e.g. application logs) with the default zip driver, confirm disk/retention behaviour over a couple of cycles, then roll out. Validate that the required PHP extensions exist in our production images before we commit to a format.