Laravel Mass Update Laravel Package

Product Decisions This Supports

• Bulk-edit and per-row update features. Any admin or operational surface where many records each receive a different value — price overrides, stock levels, manual sort order, per-tenant settings, moderation states — becomes a single UPDATE ... CASE WHEN statement instead of N round trips. This is the package's core value and the main reason to adopt it.
• Sync and write-back pipelines. When reconciling an external system (ERP, PIM, CRM, marketplace) the payload is a list of records with distinct values; after diffing, mass-update is the write-back step that avoids one query per changed record.
• Backfills and data migrations. Correcting denormalized columns, recomputing flags, or repairing millions of rows without dispatching a job per row or blowing a queue's runtime budget.
• Build vs. buy. The behavior is a thin query-builder concern: hand-rolling CASE/WHEN SQL plus chunking, binding limits, and driver quirks is real work with real edge cases, so adopting a small package is usually cheaper than owning it — unless your dependency policy forbids single-maintainer libraries, in which case the fallback (an internal CASE builder) is genuinely small.
• Competitive framing against native Laravel. Model::upsert() covers insert-or-update; this package covers update-only. Choosing between them is a product decision about semantics (do unknown keys get created?) and driver support, not a matter of capability.
• Roadmap and platform-upgrade planning. 2.0.0 signals the package tracks Laravel's release cadence — Laravel 13 support is already in — so it does not become a blocker in the framework upgrade. The breaking change is a scope reduction: one custom helper removed in favor of a framework primitive, which means less package-specific API for the team to learn and fewer behaviors that can diverge from Eloquent.
• Migration decision now on the table. Mode::massUpdateQuietly() is gone in 2.0.0. Any code path using it must move to Model::withoutTimestamps(). This should be scoped as a line item in the same sprint/PR as the Laravel 13 bump, not as an independent project. If the platform upgrade is not imminent, pinning ^1.0 is a legitimate "decide later" — but put the migration on the roadmap so it doesn't surface as unplanned work.

When to Consider This Package

Adopt when:

• You update many existing rows with distinct values per row — roughly hundreds to millions — and the current implementation is a loop of save()/update() calls.
• Round-trip count and wall-clock time matter: queue workers with time limits, API endpoints with gateway timeouts, cross-region or high-latency database connections.
• Rows can be identified by a stable unique key and you are comfortable with query-builder semantics — no model events, no observers, no per-row mutators firing. Values must be transformed before they reach the call.
• You want chunked execution to cap memory use and lock duration rather than emitting one enormous statement.
• Your stack is a supported driver (MySQL/PostgreSQL/SQLite — verify SQL Server explicitly before committing) and a Laravel version in the 11+/13 range that 2.0.0 targets.

Look elsewhere when:

• The update is uniform (->update(['status' => 'archived'])). Native Eloquent, no dependency needed.
• You need insert-or-update semantics — Model::upsert() is native, well understood, and covers the common sync case.
• You require per-row events, audit trails, versioning, or lifecycle hooks. Query-builder updates bypass all of it; use individual saves, a job per record, or a dedicated auditing package. Do not adopt this and then bolt an audit layer on top.
• The per-row logic is better expressed in the database (triggers, stored procedures) or belongs in an ETL tool (Airbyte, dbt) upstream of the application.
• Batches are small (under ~50 rows). A transaction of individual saves is simpler, fires events, and is fast enough.
• Dependency governance forbids small, single-maintainer packages. The correct move is then to copy the CASE-building approach internally rather than adopt.

Timestamps caveat worth flagging before adoption: because updates go through the query builder, updated_at handling is explicit rather than automatic. Confirm during evaluation whether you want withoutTimestamps() or an explicitly set updated_at in the payload, and test that behavior — it is the single most common source of "why didn't this row's timestamp change" bugs in this pattern.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free, open-source library that turns "update 50,000 rows with 50,000 different values" from 50,000 database queries into one. That means faster bulk operations in the admin and sync paths, fewer timeouts and retries, and less load on the database — infrastructure savings with no licensing cost and no vendor commitment. The 2.0.0 release adds support for the next Laravel version and removes a custom helper in favor of a built-in framework method, which is a good sign: the maintainer is shrinking the surface area rather than growing it, which lowers long-term risk. The upgrade cost is one method call to replace. The main risk is that the package has a very small maintainer base; it is mitigated by a narrow API that our team could reimplement internally in roughly a day if the project were ever abandoned.

For engineering (the actual ask):

• 2.0.0 is a major release. Breaking change: Mode::massUpdateQuietly() is removed. Replace with Model::withoutTimestamps() per the Laravel docs (laravel.com/docs/11.x/eloquent#timestamps). This is a mechanical, greppable change — search for massUpdateQuietly and expect a small diff.
• Sequence it with the Laravel 13 upgrade rather than as separate work. If we're not moving to 13 yet, stay pinned to ^1.0; nothing in 2.0.0 is a feature we need today.
• Add or extend a test asserting updated_at behavior after the migration — the helper that disappeared was the thing implicitly controlling timestamps in quiet mode, so that is the regression risk, not the update logic itself.
• Verify our driver is exercised in CI for the mass-update path (MySQL/Postgres/SQLite supported; SQL Server unconfirmed).
• Do not use this for insert-or-update flows; that is upsert(). And do not use it where per-row observers or audit logging are required — it bypasses model events by design.