Doctrine Profiler Bundle Laravel Package

Product Decisions This Supports

• Prioritizing performance features on evidence, not anecdotes. A query-level profiler turns "the app feels slow" into a ranked list of slow/frequent queries, which lets you decide whether the next sprint goes to indexing/schema work, caching, or UI work.
• Build vs. buy for observability. If the team is weighing a paid APM (New Relic, Datadog, Blackfire) against in-house tooling, a low-cost Doctrine profiler is a data point for the "buy later" side — useful for early-stage products where DB latency is the dominant user-perceived slowness.
• Roadmap sequencing for data-layer rework. Profiling output supports decisions like "denormalize now vs. defer to Q3," "add read replica," or "move hot reads to cache," because it quantifies query volume and duplication per request.
• Scoping N+1 and ORM-hygiene work. Identifies lazy-loading loops and repeated queries, which is often the cheapest large win in a Doctrine-backed app — useful for sizing a "performance hardening" epic.
• Incident/regression triage. When a release degrades p95 latency, per-query timing helps isolate whether the regression is query count, query shape, or infrastructure.
• Use cases: pre-launch performance audits, capacity planning before a traffic event, onboarding engineers to an unfamiliar data model, and validating that an optimization actually removed the query it claimed to.

When to Consider This Package

Consider it if:

• The stack is Symfony with Doctrine ORM/DBAL — this is a Symfony bundle, not a Laravel package. Mislabeling it as "Laravel/PHP" is the single biggest adoption risk here; there is no Laravel service provider and no Eloquent integration.
• You need a zero-cost, self-hosted, dev-environment-only query profiler and already run the Symfony Web Profiler.
• You are on a legacy Symfony/PHP version that current profiling tools no longer support — this may be its only real niche. Note the v1.0.8 change (below) points the opposite way: it moves the bundle forward to the twig service and away from the removed templating service, so it is drifting off legacy stacks rather than shoring them up.
• You want to read a small, permissively licensed (BSD-3-Clause) codebase rather than adopt a black box.

Look elsewhere if:

• The product is Laravel. Use Laravel Debugbar, Telescope, or Clockwork instead; they are maintained and native.
• You need production profiling or continuous observability — Blackfire, Tideways, or a hosted APM are the right tools; a dev-toolbar bundle should not be load-bearing in production.
• You require active maintenance. The project still sits at ~47 stars and 0 dependents. The 2019-09-14 release cited in the prior assessment has been superseded by v1.0.8, but that release is a single-line service-ID swap (templating → twig), not a maintenance program: no test-infrastructure changes, no Doctrine-version support statement, no CI signal. Treat "has a newer release" as evidence the maintainer is reachable, not that the project is maintained.
• Security/compliance review flags unmaintained transitive dependencies. Sourcing risk is real even for dev-only tooling, because it tends to get copy-pasted into CI.
• Baseline Doctrine/Symfony tooling already answers the question. Symfony's built-in Doctrine data collector in the Web Profiler covers query count and timing for most teams — verify this bundle offers something the platform doesn't before spending integration time.

Adoption gate: treat this as a reference implementation to fork or clone into a dev-only bundle, not as a dependency to add to composer.json and forget.

How to Pitch It (Stakeholders)

For executives (one paragraph): We have an opportunity to make performance work cheaper and more defensible. Today, performance requests get prioritized on opinion; a query profiler lets us rank the actual database bottlenecks behind slow pages and target the highest-leverage fixes first. The package in question is a small, free, permissively licensed (BSD-3-Clause) tool for Symfony/Doctrine stacks. It is not a Laravel tool. It shipped a new version (v1.0.8) recently — worth noting, because the previous read was "untouched since 2019" — but the change is a one-line compatibility fix, not a sign of active stewardship, and the project still has effectively no downstream users. My recommendation is unchanged and is not "adopt it"; it is "borrow the technique." The strategic value is in the decision-making capability (evidence-based performance prioritization), which we can get from maintained alternatives at low cost. No budget ask at this time.

For engineering: This is a Symfony bundle that hooks Doctrine's SQL logger to surface per-query timing and duplication in the dev profiler. Three caveats before anyone installs it: (1) we are a Laravel shop — this does not apply to our stack, and the equivalent is Debugbar/Telescope/Clockwork; (2) the headline claim in our earlier writeup, "no release since 2019," is now stale — v1.0.8 swaps the deprecated templating service for the twig service, which is a genuine forward-compat fix against modern Symfony but also confirms the bundle has no meaningful test or Doctrine-version support story behind it; (3) with zero dependents, pinning or patching against modern Doctrine is still likely. Action: I want a short spike comparing our current visibility (Telescope/Debugbar) against what a query-level profiler would add. If the gap is real, we evaluate maintained options (Blackfire/Tideways) before considering a vendored fork. Please don't add this to composer.json in the meantime — and note the new tag doesn't change that.