Laravel Mysql Optimizer Laravel Package

Technical Evaluation

Architecture fit. The package is a textbook-narrow Laravel library: one service provider (auto-discovered via extra.laravel.providers), one publishable config (mysql-optimizer.php), one Artisan command (db:optimize), one action (OptimizeTablesAction), and a queueable job (OptimizeTablesJob). It introduces no migrations, models, routes, controllers, or HTTP surface, so it cannot perturb our domain architecture. For any Laravel 8+ application on MySQL/MariaDB it slots in at the console/scheduler edge without touching application code — the entire integration boundary is "a scheduled command that calls DDL." That is the lowest-risk shape a package can have.

Integration feasibility. Trivially installable (composer require, optional vendor:publish), with sensible defaults: target DB resolves from mysql-optimizer.database falling back to DB_DATABASE; --table is repeatable for scoped runs; --queued switches to a ShouldQueue/ShouldBeUnique job; --no-log reduces noise. The engineering hygiene is above average for a 3-star package: PSR-12 via Pint, PHPStan, Pest Unit/Feature/Integration suites under Testbench, a real MySQL 8.0 integration suite, a Redis integration suite that spins up three concurrent workers, Dependabot, and Release Please. The team has clearly thought about the hard part — the docs explicitly warn that $backoff does not extend Redis retry_after, that job timeout plus safety margin must fit under retry_after, and that Horizon supervisors need their own timeout between the two. That is unusually mature guidance.

Technical risk. Essentially none of the risk lives in the package code; it all lives in OPTIMIZE TABLE. On InnoDB this is mapped to ALTER TABLE ... FORCE — a full table rebuild. It is online in modern MySQL but is I/O-heavy, takes a metadata lock, needs roughly the table's size in free disk, and produces replication lag on large tables. A thin wrapper cannot de-risk that, and this wrapper exposes no guardrails: no pre-flight disk-space check, no fragmentation gate (nothing reads data_free to decide whether a table is even worth optimizing), no dry-run despite the repo's own console-command rules calling for one, no per-table timeout sizing, and no persisted results — outcomes are table/success/timestamp written to Laravel logs, so there is no audit trail of what ran, how long it took, or how much space it reclaimed. Secondary risks: single maintainer, 3 stars, 0 dependents (bus factor); no LICENSE file despite MIT being declared in composer.json/README (legal will ask); missing CONTRIBUTING.md/CODE_OF_CONDUCT.md that the README links to; and the AGENTS.md asserts Laravel 8–13 support and PHP 8.2–8.5 CI, which needs verifying against actual composer.json constraints before we rely on it.

Key questions.

1. Is MariaDB actually supported, or only assumed? Integration CI runs MySQL 8.0 only — the description claims MariaDB. Which of our target engines is empirically verified?
2. Does --dry-run exist? The documented signature is --database, --table, --queued, --no-log only. If not, can we get it, or must we build pre-flight ourselves?
3. What privileges does our app's DB user actually have? MySQL requires SELECT/INSERT on the table; our managed-service grant set may differ, and giving the app DDL-capable grants is a security decision, not a package decision.
4. What is the largest table we'd ever target, and how long does a rebuild take on it relative to the 3600s default job timeout?
5. Is this running against a primary, a replica, or an Aurora/RDS instance? Managed engines often restrict or reinterpret OPTIMIZE, and rebuilds churn storage and lag.
6. In a multi-connection/multi-tenant app, does DB_DATABASE fallback silently point at the wrong schema?
7. Is the Laravel 13 constraint real, and what is the minimum PHP version we must be on?

Integration Approach

Stack fit. Zero additional dependencies and no framework coupling beyond the service provider. It composes cleanly with the Laravel scheduler, the app's existing queue connection, and Horizon — all of which we already operate. The only thing it requires from us is a database user with table-rebuild privileges and, if we ever use queue.per_table, a dedicated queue connection with exactly one worker.

Migration path. There is no data or schema migration; "migration" means adding one scheduler entry. Reversibility is total: remove the schedule line, composer remove, drop the published config. Rollback after a bad run is not a code problem — it's a database-restore problem, which is why the pilot sequencing below matters more than the install.

Compatibility. Verified: MySQL 8.0 (CI). Unverified by the project: MariaDB, Percona, Aurora, RDS, Cloud SQL. Also unverified for us: our PHP version against their 8.2–8.5 CI floor, and our Laravel version against their stated range. Treat the claimed matrix as a hypothesis to test in staging, not a guarantee.

Sequencing.

1. Reconnaissance, no install. Run the INFORMATION_SCHEMA.TABLES query by hand against production replicas to identify genuinely fragmented tables (data_free relative to data_length). Establish which tables, if any, justify a rebuild. This step may conclude "none" and end the evaluation.
2. Package install on staging, config published, db:optimize --help captured to confirm the actual option set (dry-run question resolved here).
3. Pilot on a staging clone with production-sized tables and production-like read/write load. Measure rebuild duration, disk headroom consumed, metadata-lock wait, and replica lag. This produces the number that sets our timeout.
4. Single production run, synchronous, in a maintenance window, on one small, non-critical table, with a rollback plan and DBA present.
5. Move to queued mode on the default queue, scoped with explicit --table lists rather than "all tables," scheduled at a frequency matched to observed fragmentation growth (weekly or monthly, not nightly).
6. Only then evaluate queue.per_table fan-out — and only if step 3 showed monolithic sequential runs cannot fit the window. It requires provisioning a dedicated connection, queue, and single-worker supervisor, which is a real infrastructure cost for a marginal concurrency gain.

Recommendation to gate on step 1: if reconnaissance shows our InnoDB tables have low data_free, the correct decision is to not adopt this at all. The package is the easy part; the rebuild is the expensive part.

Operational Impact

Maintenance. Small dependency surface, active automation, weekly Dependabot PRs, automated releases. The real maintenance liability is governance: a single-maintainer project with no license file, unresolved README links, and TODO markers in its own agent docs. Mitigate by wrapping db:optimize behind our own scheduled command (or a thin internal Artisan command that calls it with our fixed table list and config), so the vendor package becomes a swappable implementation detail rather than a direct scheduler target. The declared MIT license and trivial codebase mean forking is a viable escape hatch — confirm with legal that the absence of a LICENSE file doesn't undermine that.

Support. No community to lean on. Notably, the vendor's own guardrail policy is "do not work around bugs in gigerit/* dependencies in the consuming project — stop and report." That's good discipline internally, but as a consumer it means upstream defects become a blocked ticket against a small team's bandwidth. Budget for that, and make sure our runbook includes "file upstream, implement local fork if SLA is breached." Escalation path is GitHub issues only.

Scaling. Two axes. Vertical: a single table's rebuild must fit within the 3600s default job timeout — if it doesn't, the worker is killed mid-DDL while MySQL continues the operation server-side, leaving us blind until it finishes. Size the timeout to the largest target table measured in the pilot, and split table lists across schedules rather than raising the timeout indefinitely. Horizontal: the default queued mode is one monolithic sequential job; total window = table count × per-table duration. queue.per_table fans out but is explicitly documented as requiring a dedicated single-worker queue, and its safety depends on retry_after exceeding job timeout plus a safety margin, plus Horizon supervisor timeout sitting between them. Misconfiguration silently produces concurrent OPTIMIZE runs on the same instance — the worst failure mode here. Avoid per-table mode unless step 3 proves it is necessary.

Failure modes to plan for.

• Metadata lock contention: the rebuild waits on or blocks concurrent queries; on a hot table this cascades into query pile-up and timeouts for the application.
• Disk exhaustion: the rebuild needs roughly the table's size free; filling the volume takes the database down.
• Replication lag: large DDL on primary pushes replicas behind, degrading read traffic.
• Partial completion: no resumability and no persisted run record beyond logs — reruns must be reasoned out by a human. --no-log makes this worse; keep logging on.
• Reservation expiry / duplicate execution: tries = 1 means no automatic retry, but uniqueFor = 0 releases the uniqueness lock on failure and Redis retry_after can outlive the job lock. This is the exact scenario the project documents and the exact one we are most likely to hit if we get queue config wrong.
• Wrong-target risk: silent DB_DATABASE fallback in multi-tenant apps.

Ramp-up. Installing the command is a ten-minute task; operating it safely is a database-operations task. The knowledge required is retry_after math, Horizon supervisor configuration, InnoDB online-DDL behavior, maintenance-window discipline, and disk-capacity forecasting — none of which the package supplies and most of which app developers don't carry. Assign ownership to a DBA/platform engineer, not the feature team, and require a written runbook covering: which tables, why, schedule cadence, pre-flight disk check, post-run lag check, and the abort procedure. The package is cheap; the operational ownership it implies is not.