Laravel Boolean Softdeletes Laravel Package

Product Decisions This Supports

• Data lifecycle modelling for user-facing "archive/restore" features. The package swaps Laravel's timestamp-based deleted_at for a boolean flag, which is the right primitive when a record's deletion state must participate in compound unique indexes (e.g. one active account per email, unlimited archived ones) or when "is this row live?" needs to be a cheap indexed boolean predicate rather than a NULL check.
• Roadmap signalling: Laravel 12 readiness. v7.0 explicitly adds Laravel 12 support, so this unblocks any upgrade planning item that was gated on third-party dependency compatibility. Treat it as a checkbox on the framework-upgrade epic, not a feature in itself.
• Build vs buy on tenancy/domain soft-delete semantics. Building a bespoke boolean-delete trait inside your own codebase is a small but non-trivial surface (query scopes, restore, force-delete, relations, migration column types). Adopting a maintained package is the cheaper call — provided you accept the trade-offs listed below.
• Migration/runtime cost decisions. The v7.0 performance work on migrations means large-table adoption (adding the boolean column, backfilling, indexing) is less of a rollout risk. That makes retrofitting existing tables more viable than it would have been on v6.
• Use cases where this is a natural fit: subscription/membership records that must retain history, multi-tenant rows where "active" must be queryable per tenant, catalogue items that are unpublished vs removed, and any table where you need uniqueness scoped to non-deleted rows.

When to Consider This Package

Adopt when:

• You have a unique constraint that must ignore soft-deleted rows — the classic deleted_at IS NULL + unique index conflict. A boolean column gives you UNIQUE(email, is_deleted) style indexes that behave predictably across MySQL, PostgreSQL, and SQLite.
• Your queries filter on "not deleted" constantly and at scale, and you want a compact, index-friendly boolean rather than a nullable timestamp.
• You are on, or moving to, Laravel 11/12 — v7.0 confirms current-framework support, so there's no compatibility tax.
• You want standardised semantics across teams rather than each service reimplementing a soft-delete trait.

Look elsewhere or stay on timestamps when:

• You need "who deleted it and when" as first-class audit data — a boolean carries no timestamp. You'd need a separate audit log, which erodes most of the simplicity gain.
• Your codebase, tooling, or team conventions already assume deleted_at — Eloquent's trashed(), onlyTrashed(), restore(), Prunable, and most Laravel ecosystem packages (admin panels, audit trails, Nova/Filament filters) assume timestamps. Migration cost is real.
• You rely on retention/pruning policies keyed on deletion age; a boolean gives you nothing to prune on.
• It's a small, single-app codebase — a 30-line trait in app/Models/Concerns may be cheaper than a dependency, and avoids a vendor-owned core data concern.
• You need hard guarantees on data integrity across DB engines — evaluate whether your target DB supports the partial/functional indexes you'd want.

Also note this is a single-vendor package from TenantCloud with a modest contributor base. v7.0 being a major version bump with no documented BC breaks beyond framework support suggests the major was cut for the Laravel 12 floor — confirm the minimum PHP/Laravel versions before planning the upgrade, and check whether v7 still supports the Laravel version you're currently on if you're mid-upgrade.

How to Pitch It (Stakeholders)

For executives: This is a small infrastructure dependency, not a product feature. The relevant news is that v7.0 adds support for Laravel 12, which removes a blocker from our framework-upgrade timeline. There is no new user-facing capability and no commercial impact. The decision it informs is a technical one — whether to standardise how we mark records as "removed but retained" — and the risk is low and reversible.

For engineering: v7.0 is a compatibility and performance release. It brings Laravel 12 support and optimises migration performance, which lowers the cost of adopting boolean soft deletes on existing large tables. We should confirm the minimum PHP/Laravel version for v7 and check the diff for any silent BC changes to the trait's scopes before bumping. The substantive architectural question is separate from the release: timestamp-based deleted_at is woven through Laravel's own APIs and most of the ecosystem, so adopting boolean deletes is a deliberate trade — we gain clean compound-unique indexes and a cheaper "is live" predicate, and we give up free deletion timestamps and out-of-the-box compatibility with tooling that assumes deleted_at. Recommendation: treat the upgrade as routine, and evaluate the boolean-soft-delete pattern only for tables where the unique-index problem actually bites.