Laravel Mysql Optimizer Laravel Package

Product Decisions This Supports

• Build vs. buy for a recurring ops chore. OPTIMIZE TABLE scheduling is a ~1-day engineering task that most teams never get around to. This package replaces that with composer require plus a scheduler entry, so the real decision is "do we spend a sprint-day of platform engineering, or a dependency?" — not "which optimizer library."
• Roadmap placement of database maintenance. Gives you a concrete, shippable line item (e.g., "automated table maintenance for MySQL/MariaDB") that closes a recurring ops/on-call complaint without competing for core product capacity. Good candidate for the "small bets / operational debt" bucket rather than the feature roadmap.
• Whether to invest in DB performance work at all. The package only addresses physical table maintenance (fragmentation, index/table rebuilds). If your actual pain is slow queries, missing indexes, or N+1s, this is a visible-but-wrong lever — use it to explicitly rule out DDL maintenance as your bottleneck before funding query optimization.
• Buy vs. fork the internals. Scope is deliberately tiny (one command, one action, one job, one config file) with no migrations, models, routes, or HTTP surface. That makes "adopt now, fork later if abandoned" a viable option rather than an all-in vendor commitment — and it caps the switching cost you should model in the business case.
• Platform standardization. If you run multiple Laravel services on MySQL/MariaDB, adopting one blessed db:optimize command standardizes how maintenance runs (same flags, same logging, same queue semantics) instead of each team hand-rolling mysql -e "OPTIMIZE TABLE ..." in a cron script.
• Scheduling architecture. Supports both synchronous CLI execution and queueable (--queued, ShouldBeUnique, per-table fan-out) modes, which is really a decision about where maintenance runs: deploy-window command vs. background worker vs. per-table parallel jobs on a dedicated queue.
• Risk appetite calibration. With 3 stars and 0 dependents there is essentially no community validation, so adopting it is a deliberate "low blast radius, low social proof" trade — useful for setting expectations with stakeholders that this is an ops convenience, not a strategic bet.

When to Consider This Package

Consider adoption when all of these hold:

• You are on Laravel 8–13 / PHP 8.2–8.5 and the datastore is genuinely MySQL or MariaDB — the package is engine-specific and does nothing elsewhere.
• You have self-managed or unmanaged MySQL where you control the DDL: bare metal, VMs, Docker, or a permissive managed offering where OPTIMIZE TABLE is allowed.
• Your tables are large, append-heavy, or delete-heavy (logs, events, sessions, audit tables) where rebuilds plausibly reclaim space or reduce fragmentation.
• You can run maintenance in a low-traffic window and accept that OPTIMIZE TABLE may lock or rebuild tables; you already have a maintenance-window convention.
• Your queue infrastructure is well understood — you can reason about retry_after, worker timeouts, and (for per-table fan-out) a dedicated single-worker queue.
• You want zero integration surface: no HTTP, no schema changes, no new models — a config publish plus a scheduler line.
• You are comfortable with single-maintainer / vendor risk and have a fork-and-own fallback already scoped.

Look elsewhere when:

• You are on PostgreSQL, SQL Server, or SQLite — no overlap at all.
• You are on Aurora, RDS, PlanetScale, or similar, where OPTIMIZE TABLE is often restricted, unnecessary for InnoDB (which self-maintains and reuses space within the tablespace), or where the managed engine's own maintenance already covers you. Validate with your DBA before buying the premise.
• Your bottleneck is queries, indexes, or schema design — this package ships no EXPLAIN tooling, no index advisor, no slow-query analysis.
• You need observability and reporting: reclaimed bytes, before/after row counts, per-table timing trends, Prometheus/OpenTelemetry export. Current logging is Laravel logs plus console output only.
• You need --dry-run, approval gates, or change-management audit trails — not in the documented surface.
• You need active maintenance guarantees: no LICENSE/CONTRIBUTING/CODE_OF_CONDUCT files in-repo, low star count, no dependents, and release history driven by automated Release Please. Fine for a convenience wrapper; not fine if your procurement process requires vendor viability.
• You are already large enough to have a DBA/platform team — they will likely prefer scheduled pt-online-schema-change-style tooling or native engine maintenance with their own runbooks, and they will push back on an app-level package issuing DDL.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, MIT-licensed Laravel package that automates routine MySQL/MariaDB table maintenance we currently do manually or not at all. It adds one Artisan command and an optional background job, installs in minutes, and requires no schema changes or new services — so the cost is near zero and the risk is contained to a scheduled maintenance window. The trade-off is that it comes from a single maintainer with minimal community adoption, so we should treat it as an internal convenience we can fork if needed, not a strategic dependency. Recommendation: pilot on one non-critical database, measure whether it actually reclaims space or improves performance, and only then roll it out.

To engineering (the ask): Adopt gigerit/laravel-mysql-optimizer behind a scheduled command, gated to a low-traffic window, with an explicit decision recorded on sync vs. --queued execution. If queued, validate that job timeout plus the package safety margin sits below Redis retry_after, and keep per-table fan-out (queue.per_table) off by default — if enabled, it must run on a dedicated, explicitly named, single-worker connection. Treat ShouldBeUnique, $tries, and $backoff as not protection against reservation expiry. Confirm with the DBA that OPTIMIZE TABLE is permitted and meaningful for our engine/version before scheduling. Budget roughly a day: install, publish config, schedule, verify on a disposable database with test tables.

To security/compliance: Minimal footprint — no HTTP routes, controllers, views, or migrations; DB and table names are validated through INFORMATION_SCHEMA before execution. The operation requires DDL privileges and can lock tables, so scope credentials narrowly and document the maintenance window.

Success criteria for the pilot: (1) command runs clean on a non-production replica for two cycles; (2) measured reclaim on at least one large table, or a documented decision that none is needed; (3) no lock-related incidents during the window; (4) a written fallback — fork the package or revert to a hand-rolled command — in case upstream goes quiet. If (2) fails, kill it and redirect the effort to query/index optimization, which is where the actual gain likely lives.