- Does sarfraznawaz2005/indexer work with Laravel 10 and Laravel 11?
- Unverified. The last tagged release is from October 2021, which places the package in the Laravel 8 era, so Laravel 9, 10 and 11 plus PHP 8.1 to 8.3 compatibility is not proven. Because the DB::listen API it depends on is stable, a fork-level patch to the composer constraints is usually cheap if that is the only blocker. Always run a one-day spike on your actual Laravel and PHP pair before committing.
- How do I install sarfraznawaz2005/indexer in a Laravel app?
- Install it as a development dependency with composer require --dev sarfraznawaz2005/indexer, then optionally publish the config file and enable it through an environment flag. There is no migration, no schema change and no external data store to provision, so removal is just a composer remove plus deleting the config. Keep it inside require-dev rather than require so it can never load in production.
- Is it safe to run this indexer package in production?
- No, treat it strictly as a development-time diagnostic. Captured SELECT statements can contain literal values and therefore PII, so the tool should be hard-disabled outside local and staging via APP_ENV or an explicit INDEXER_ENABLED flag. Confirm that no query capture occurs when the flag is off, and review any persistence layer before pointing it at real data.
- How does sarfraznawaz2005/indexer decide which indexes to suggest?
- It hooks Laravel's query event pipeline with DB::listen, captures SELECT statements, parses their WHERE and JOIN predicates, and emits candidate index recommendations from that static analysis. That means the output is a heuristic, not a query plan, so it has no awareness of selectors like cardinality, write amplification or your existing indexes. Treat every suggestion as a hypothesis and validate it with EXPLAIN on production-like data.
- Does it suggest composite indexes or only single-column indexes?
- This is one of the open questions the package documentation does not clearly answer, so verify it in your spike. Static predicate parsing typically struggles with composite column ordering and selectivity, producing suggestions that are directionally useful but wrongly ordered. Never apply a multi-column recommendation without checking it against EXPLAIN.
- Which databases are supported: MySQL, Postgres or SQLite?
- MySQL is the natural target and the driver the tool is most likely exercised against. Postgres and SQLite behavior, including expression indexes and Postgres-specific plans, is unproven, so a Postgres-primary stack should treat this package as unsupported until you verify it. Check which drivers your spike actually exercises before drawing conclusions.
- Where do the index suggestions show up: log, route or UI?
- The surfacing mechanism is not documented clearly and needs to be confirmed during evaluation, since it may be a log entry, a route, a UI or stored output. Whichever it is, it determines how much captured query text leaves memory. Run a few representative read paths on staging and confirm suggestions are actually produced and readable.
- What is the performance overhead of capturing queries with this package?
- Query capture buffers in memory, so high-volume local runs and CI suites can see distorted timings or growing memory usage. There is no documented cap on how many statements are retained, which makes long-running sessions a risk. Keep capture windows short and confirm the memory profile under a realistic load before trusting benchmark numbers produced alongside it.
- Is this package redundant if I already use Laravel Telescope or Datadog?
- Largely yes. Teams standardized on APM and database observability such as Datadog DBM, Percona PMM, or Telescope plus manual EXPLAIN work already have better-indexed data and will find this additive at best. It fits best in a Laravel monolith on MySQL where index tuning is still ad hoc and nobody wants to provision Elasticsearch or Algolia for it.
- Is sarfraznawaz2005/indexer still maintained, and should I fork it?
- Treat it as unmaintained open source: roughly 56 stars, a single maintainer, no release in about four years and a low composite score, so assume no security patches and no Laravel version bumps. If you adopt it beyond a pilot, vendor or fork it into your own namespace and own the few hundred lines. That removes the version-constraint risk permanently and keeps the removal path to a single commit.