Doctrine Doctor Laravel Package

Product Decisions This Supports

• Performance Optimization Roadmap: Justify investment in query optimization with concrete, actionable runtime insights (N+1 queries, missing indexes, unbounded findAll()) at near-zero engineering cost. Directly targets technical debt in legacy Symfony/Doctrine codebases.
• Build vs. Buy: Buy—reimplementing runtime query analysis for Doctrine is not a differentiator. The 90+ analyzers cover edge cases (unbounded result sets, bidirectional cascade issues, unsafe DQL) that static tooling misses.
• Developer Experience Investment (new in v2.11.2): The runtime analysis no longer blocks the request—parser caching, deferred on_view timing, and a lazily built pending-analysis listener mean profiling no longer taxes page loads in dev. This removes the single biggest adoption objection for profiler-based tooling ("it makes my dev environment slow") and makes the package safe to leave permanently enabled.
• Security Compliance: Flags SQL injection risks (unsafe QueryBuilder usage) and sensitive data exposure, reducing manual security audit surface.
• Developer Productivity: Shifts query optimization from post-deployment debugging to in-request feedback in the Symfony Profiler, with backtraces to the exact template/controller line.
• Data-Driven Refactoring: Enables prioritization with cost framing (e.g., "this N+1 costs 2.3s per request"), turning performance work into a ranked backlog rather than a guess.
• Onboarding Acceleration: Standardizes Doctrine best practices (e.g., "never findAll() without limits") via configurable thresholds, so conventions are enforced by tooling instead of code review.

Use Cases:

• Migrating from raw SQL to Doctrine ORM (surfaces anti-patterns early).
• Pre-release hardening for high-traffic launches (catches slow queries before staging).
• Auditing third-party bundles for Doctrine inefficiencies.
• Enforcing architectural standards (e.g., "no EntityManager in entities").
• Running the profiler continuously in dev without a latency penalty (viable as of v2.11.2).

When to Consider This Package

Adopt if:

• Your Symfony app uses Doctrine ORM 3.x/4.x and shows performance symptoms (slow pages, high DB load, ballooning query counts).
• You lack dedicated backend performance engineers or an APM (no Blackfire/New Relic), and need profiling that ships in the profiler developers already use.
• Security is a priority (fintech, healthcare) and you want runtime DQL/SQL injection detection in addition to static rules.
• Your team repeatedly hits N+1 queries or missing indexes, typical of fast-growing or legacy codebases.
• You want zero-configuration setup (Symfony Flex) with no production overhead—and, since v2.11.2, no meaningful request-blocking overhead in dev either, so it can stay on by default.
• Developer velocity matters more than tooling purity: teams that abandoned profiler extensions for being slow should re-evaluate.

Look elsewhere if:

• You're not on Symfony (the package integrates with the Symfony Profiler and its data collector).
• Your app is read-heavy with simple, already-tuned queries—there is nothing to detect.
• You already run Blackfire/New Relic and your team is committed to their query analysis; this is complementary, not a replacement for deep dives.
• Your team mandates static analysis only (PHPStan/Psalm); this tool catches runtime facts (actual query counts, real backtraces) that static tools cannot.
• You use Doctrine DBAL directly (ORM-specific analyzers won't apply).
• Your database can't run EXPLAIN (limits missing-index detection).

How to Pitch It (Stakeholders)

For Executives

"Doctrine Doctor is a 10-minute setup that automatically surfaces the top three performance killers in our Symfony app—N+1 queries, missing indexes, and injection-prone query code—without adding headcount. It lives inside the profiler our developers already use, so problems are fixed while coding, not after customers notice. Recent releases also removed the profiling overhead that usually comes with tools like this: analysis no longer blocks requests, so we can leave it on for every developer, every day. The ROI is immediate: faster pages, lower database spend, fewer production incidents."

Key metrics to highlight:

• Time saved: "Reduces query debugging from hours to minutes per issue."
• Cost avoided: "Prevents over-provisioned database spend by removing slow queries at the source."
• Risk reduced: "Catches SQL injection anti-patterns before they reach production."
• Adoption friction removed: "Zero request-blocking overhead in dev as of v2.11.2—no trade-off between insight and speed."

For Engineering Teams

"Think Blackfire for Doctrine, built into the Symfony Profiler—free, no agents, no instrumentation. It doesn't just say a query is slow; it says why ('this findAll() fired 100 times because addSelect() is missing') and links the exact Twig/controller line. The latest release (v2.11.2) also fixed the thing that made profiler tooling annoying: analysis is now cached, on_view timing is deferred, and the pending-analysis listener is built lazily—so opening a page in dev no longer waits on the analyzer. Leave it enabled; you won't feel it."

For Developers:

• "Install in 30 seconds; see critical issues on your first page load."
• "Backtraces point to the exact line in your template or controller."
• "Suggested fixes are copy-pasteable—no Doctrine docs safari required."
• "Profiling no longer blocks the request, so it's safe to keep on all the time."

For Tech Leads:

• "Standardizes Doctrine best practices across the team ('no findAll() without limits')."
• "Catches slow queries in dev instead of on-call."
• "Complements Blackfire: this for continuous early-stage feedback, Blackfire for deep dives."
• "Upgrade path from v2.7.x is clean—no breaking changes flagged; the 2.11 line is purely performance and stability hardening."

Demo Script for Engineers:

1. "Open your Symfony app in dev mode, load a page, and click the Doctrine Doctor tab in the Profiler."
2. "See that red Critical issue? That's an N+1 firing 100 times—here's the exact Twig line causing it."
3. "Click Suggested Fix: a one-line addSelect() change removes the extra queries."
4. "Notice the page loaded at normal speed—v2.11.2 caches the parser and defers analysis, so the profiler never sits in your critical path."