Doctrine Query Statistics Bundle Laravel Package

Product Decisions This Supports

• Diagnosing ORM performance in development: gives engineers a per-request view of Doctrine query counts, execution time, and duplicate queries, which supports decisions like "is this endpoint slow because of the database or the application layer?" and "do we need to prioritize a query-optimization sprint?"
• N+1 and query-hygiene triage: makes repeated/duplicate queries visible during feature development, supporting go/no-go decisions on a release where a new page ships with a known query-count regression.
• Performance budget enforcement: the numbers this surfaces are the raw input for a team-level policy such as "no request exceeds N queries" or "no page exceeds X ms in DB time," which is a product decision about acceptable latency and infrastructure cost.
• Build vs. buy for internal observability: benchmark against what you would otherwise build (custom Doctrine SQL logger, middleware, dashboards). For most teams the honest answer is "buy the built-in profiler, don't build a bundle."
• ORM / framework modernization arguments: concrete query statistics are the evidence base for decisions like "stay on Doctrine or migrate," "introduce a read replica," or "add caching at the repository layer."
• Reference value, not dependency value: because the project is archived, its real product use is as a design reference for what query statistics your team should surface in its own tooling. It should inform a roadmap item ("add query-count visibility to our dev tooling"), not appear on a dependency list.

When to Consider This Package

Consider it (cautiously) when:

• The stack is genuinely Symfony + Doctrine ORM — this is a Symfony bundle, not Laravel/PHP-generic. On a Laravel/Eloquent codebase it is simply inapplicable; the equivalent need is served by Laravel Debugbar, Telescope, or a query-detection package.
• The need is development/staging-only visibility, not production APM.
• You need a fast spike to prove that query volume is the bottleneck before investing in proper tooling.
• You want a worked example of how to hook into the Symfony Profiler to add a custom data collector — the bundle is small and readable.

Look elsewhere when:

• Any long-lived production or platform dependency is implied. It is archived with zero dependents and no maintainer. There is no security response, no PHP/Symfony version compatibility guarantee, and no upgrade path. Treat archived status as a hard blocker for anything beyond a throwaway spike.
• You need maintained support. Symfony's own Profiler already exposes Doctrine query counts and timing via the DoctrineBundle data collector, and Doctrine's SQL logger covers the rest — meaning this bundle's core value proposition has largely been absorbed by the platform. That is the decisive product finding: you are not choosing between "this bundle" and "nothing," you are choosing between "this bundle" and "the feature you already have installed."
• You need production monitoring, alerting, or historical trends. A profiler tab is a per-request dev tool; it is not APM. Pair with a real observability product if the requirement is ongoing.
• The team is on Laravel, or on a non-Doctrine ORM. Wrong abstraction layer entirely.
• Compliance or security review is required for new dependencies; an unmaintained package will not clear it.

Recommendation: do not adopt as a dependency. Budget a half-day spike to confirm what the built-in Symfony Doctrine profiler panel already shows; if it is sufficient, close the ticket. If it is not, file a small roadmap item to instrument query statistics in your own dev tooling, using this bundle as a reference implementation.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, free, developer-only tool that shows how many database queries a page makes and which ones are slow or repeated. It helps engineers find and fix performance problems before customers feel them. However, it is an abandoned open-source project that has not been maintained, and the framework we use already ships substantially the same capability for free. My recommendation is not to add it to our stack: the low cost of adopting it is outweighed by the ongoing cost of owning an unmaintained dependency, and the performance visibility we want is either already available or better delivered by a small piece of our own tooling. Net investment if we proceed as recommended: negligible; the deliverable is a decision and a one-page note on what our built-in tooling covers.

To engineering leads: The bundle adds a Profiler tab with per-request Doctrine query statistics — query count, timing, duplicates. It is archived, unmaintained, zero dependents, and targets Symfony + Doctrine, so it is irrelevant if we are on Laravel. Before adopting, verify what the DoctrineBundle profiler panel and the SQL logger already give us; my expectation is that the gap is small and is better closed with a lightweight custom data collector we control. Use the source as a reference, not as a dependency. If we do want this visibility, the ask is a short spike plus a proposal for a maintained in-house collector, not a new third-party package.

Framing to use: "free to try, expensive to own." The license is MIT and the integration cost is low, so the conversation is not about price — it is about maintenance risk and redundancy with tooling we already pay for by default. Lead with the redundancy argument; it is the strongest and least political.