Doctrine Query Statistics Bundle Laravel Package

Technical Evaluation

Headline finding: stack mismatch. Despite being catalogued as a "Laravel/PHP package," sensiolabs/doctrine-query-statistics-bundle is a Symfony bundle (it extends Symfony\Component\HttpKernel\Bundle\Bundle and registers a Profiler data collector). Laravel does not use Doctrine by default, has no Symfony Profiler, and therefore has no extension point this package can hook into. The relevance score (0.60) and star count (58) reflect generic "PHP" tagging, not actual Laravel applicability.

Architecture fit. Poor for a Laravel codebase. The package's sole function is to add a "Doctrine" tab to the Symfony Web Profiler showing query count, execution time, and parameters per request. In Laravel, the equivalent responsibilities are already covered natively by Laravel Telescope (query watcher), Laravel Debugbar, and Clockwork. Even inside Symfony, the functionality was largely redundant with DoctrineBundle's own DoctrineDataCollector, which ships the same tab out of the box.

Integration feasibility. Low. Practical blockers:

• Archived repository — no upstream fixes, no security response, no PHP 8 / Symfony 5+ compatibility.
• Composer constraints almost certainly pin PHP 5.x–7.x and Symfony 2.x, so installation on a modern stack fails or requires constraint-ignoring hacks.
• Zero dependents in the ecosystem, meaning essentially no community validation or known-good integration paths.

Technical risk. High relative to the value delivered. The capability is a developer-only diagnostic, so the blast radius of failure is limited — but the cost of adoption is a dead dependency in the lockfile, an unsupported code path, and a false sense of coverage (a profiler tab is not observability).

Key questions for the team.

1. Are we actually running Symfony, or Laravel? If Laravel, this package is out of scope and the evaluation ends here.
2. If Symfony: is the native Doctrine data collector insufficient? What specific metric (duplicate-query detection, per-query parameter breakdown, aggregate timing) is missing?
3. Is there a maintained alternative — Symfony's native profiler, doctrine/sql-formatter, Laravel Telescope, Debugbar, or Clockwork — that covers the requirement?
4. What is the actual problem being solved: ad-hoc debugging, or production query observability? Only the latter warrants a build-vs-buy decision.

Integration Approach

Stack fit. Direct integration into Laravel is not viable. Recommendation: do not adopt unless the target application is a legacy Symfony 2.x/3.x service where the bundle is already installed.

If the stack is Laravel (the assumed context): treat this as a rejected candidate and substitute native tooling.

If the stack is legacy Symfony: the migration path is removal, not installation. DoctrineBundle's built-in profiler panel already surfaces query count, time, and parameters. The bundle should be dropped in favor of the native collector.

Migration path and sequencing.

1. Audit — confirm the package is (or is not) present in composer.json/composer.lock and check for transitive requirements. Given zero dependents, removal is low-risk.
2. Baseline — capture which metrics the team actually uses today (query count per request, N+1 detection, slow-query threshold).
3. Replace — install/enable the native alternative (Telescope or Debugbar; native Doctrine collector for Symfony) in local and staging only.
4. Parity check — verify the replacement reports the same metrics; document any gaps.
5. Remove — uninstall the bundle, delete service/config registration, and lock the decision in an ADR.
6. Guard — add a CI check or dependency-review rule preventing reintroduction of archived packages.

Compatibility. Any attempt to force-install on PHP 8+ will require --ignore-platform-reqs or Composer constraint overrides, which introduces non-deterministic builds and should be treated as a release blocker.

Operational Impact

Maintenance. Effectively unbounded ownership transfer. Archived means the adopting team becomes the de facto maintainer for any bug, PHP upgrade, or Symfony version bump. For a dev-only profiler tab, that is a poor trade: high ongoing cost, near-zero strategic value.

Support. No upstream maintainer, no issue triage, no security advisories. Internal support burden falls entirely on the platform team, competing with higher-value work.

Scaling. The profiler is a development-time tool and must never be enabled in production. If it were, per-request query capture imposes memory and CPU overhead proportional to query volume, and the profiler storage backend accumulates request profiles — a real risk of storage growth and latency on high-traffic services. Scaling concerns are therefore less about throughput and more about accidental enablement.

Failure modes.

• Composer resolution failure on modern PHP/Symfony (most likely outcome).
• Bundle registration errors after framework upgrades.
• Profiler storage bloat from retained profiles in non-production environments.
• Sensitive data exposure — query parameters, including PII and credentials, captured in profiler storage and potentially shared in screenshots or exported profiles. This is the most material operational risk and a common compliance finding.
• Silent divergence: developers trust a stale tool while the framework's native collector has moved on.

Ramp-up. Trivial to learn (it is a read-only tab), which is precisely why the risk is under-estimated. The real ramp-up cost is organizational: convincing the team that the "quick win" of a profiler tab is not worth an unsupported dependency. Estimated onboarding for a developer: under an hour; estimated cost of ownership over a two-year horizon: materially higher than adopting Telescope, Debugbar, or the native Symfony collector.

Recommendation. Do not integrate. Score the package reject — archived, stack-mismatched, and functionally superseded. Redirect the underlying requirement (query visibility during development) to maintained, first-party tooling, and document the decision so the same candidate is not re-evaluated on star count alone.