Symfony Doctrine Sql Logger Bundle Laravel Package

Technical Evaluation

Architecture fit. This is a Symfony bundle, not a Laravel package. It ships a Bundle class plus a DI extension and service definitions wired into Symfony's container/event system, targeting Doctrine DBAL — a data layer Laravel does not use by default. A Laravel application runs Eloquent over Illuminate\Database, so there is no natural registration point for a Symfony bundle. Fit is therefore low as a direct dependency, but moderate as a reference implementation: the value is the technique (SQL + bound-parameter interpolation, caller backtrace capture, log-level heuristics), which maps cleanly onto Laravel's DB::listen, the QueryExecuted event, or a Doctrine middleware if we already run Doctrine via laravel-doctrine.

Integration feasibility. Direct composer require into a Laravel app is a non-starter — the bundle's DependencyInjection\*Extension and Resources/config/services.* are inert outside Symfony's kernel. Feasible paths, in order of effort:

1. Port the formatting logic into a small internal package: a ServiceProvider that registers a DB::listen callback, reusing the bundle's parameter-binding and backtrace approach.
2. Reuse only under Doctrine: if a service already uses laravel-doctrine/orm, port the bundle's config to a Laravel provider and register it as a DBAL Middleware (not SQLLogger — see risk below).
3. Fork and re-package as a first-party Laravel package if the pattern proves out.

Reading the source is cheap (small codebase, MIT), so a 2–3 day spike can confirm whether the formatter is worth lifting wholesale.

Technical risk.

• Adoption signal is weak. 3 stars, 0 dependents, score 0.105. Effectively unvalidated by the ecosystem; assume single-maintainer and no compatibility matrix. Do not place it on a critical path as an external dependency.
• DBAL version drift. Doctrine DBAL 3.x deprecated SQLLogger and DBAL 4 removed it in favour of Middleware. A bundle whose name/history centres on "SQL logger" may target the deprecated API. This is a first-order verification question.
• PII/sensitive data exposure. Parameter interpolation is the bundle's core feature and its core hazard: bound values (emails, tokens, card fragments) get written to logs verbatim. Any adoption requires a redaction allowlist before it touches production.
• Log volume and I/O. Interpolating every query plus capturing a backtrace is expensive in hot paths; unbounded it can multiply log spend.
• The high opportunity score (7.93) vs. low adoption suggests a real ecosystem gap (Laravel's query log is dev-oriented and weak on parameter context) rather than a strong artifact — i.e., build the capability, don't buy this package.

Key questions for the spike.

• Which DBAL versions are supported, and is it SQLLogger or Middleware-based?
• Does it capture bindings types correctly (dates, binaries, null, arrays for IN)?
• What is the backtrace depth/cost, and is it configurable?
• Is there any redaction hook, or is everything logged raw?
• Last commit date and open-issue cadence — is it abandoned?
• Does it integrate with PSR-3/Monolog context, or emit plain strings?

Integration Approach

Stack fit. Assume a standard Laravel 10/11 app on Eloquent + MySQL/Postgres. Nothing from the bundle loads; only its design transfers. The Laravel-native equivalent is a DB::listen(fn (QueryExecuted $q) => ...) listener registered in a dedicated, toggleable service provider, reusing the bundle's interpolation routine. If the platform is polyglot (Symfony services alongside Laravel), the bundle may be deployable as-is only in the Symfony half — treat those as two separate solutions.

Migration path. Vendor the interpolator rather than depend on the repo: copy the formatting class under our namespace, keep MIT attribution, and wrap it behind an internal interface (SqlLogFormatter) so it can be swapped. This converts an unmaintained third-party dependency into ~150 lines of owned code — the correct trade at this adoption level.

Compatibility. Pin to our supported PHP/Laravel matrix and add contract tests for: named vs. positional bindings, DateTimeInterface, booleans, null, binary, and large IN lists. If Doctrine is in play, target DBAL 3 Middleware and explicitly exclude DBAL 4 until verified. Avoid the SQLLogger path entirely.

Sequencing.

1. Spike (1 week): read source, confirm DBAL/Symfony version targets, prototype DB::listen listener with interpolation in a non-prod branch.
2. Redaction design before code: define which columns/patterns are masked; make redaction mandatory, not opt-in.
3. Ship behind a config flag, default off, enabled per-environment; log at debug with sampling rather than at info for all queries.
4. Add backtrace as an opt-in "slow query" mode only (threshold-triggered), not on every query.
5. Re-package as an internal Composer package only if a second service needs it.

Operational Impact

Maintenance. As a dependency: unquantifiable risk (single maintainer, no dependents, stale-by-default). As vendored code: low — a small, self-contained formatter we own, with no upstream upgrade treadmill. Budget a few days per year plus test upkeep; the real cost is the redaction policy, which must be reviewed like any data-handling control.

Support. No vendor, no SLA, no community. Escalation = we read the source ourselves, which is realistic here given size. Document the fork origin and MIT obligations.

Scaling. Backtrace capture and per-query string interpolation are the scaling levers. Under high QPS, synchronous interpolation on the request path adds measurable CPU and, if log sinks are slow, latency. Mitigate with: sampling (e.g. 1–5% of queries), slow-query-only mode above a threshold, async log shipping, and structured context rather than pre-formatted strings so log processors can redact downstream.

Failure modes.

• PII leak into logs — highest severity; a compliance incident, not an ops one. Gate with redaction tests in CI.
• Log volume/cost explosion on a query-heavy endpoint or a retry storm.
• Latency regression from backtrace capture on hot paths.
• Silent breakage on Laravel/DBAL upgrade if vendored code reaches into framework internals.
• Divergence from upstream, making future "just take the update" impossible — acceptable, since we already decided not to track upstream.

Ramp-up. Low for any PHP engineer: the source is small and the concept (interpolate bindings into SQL, attach caller context) is widely understood. Half a day to read, one to two days to a working Laravel listener. The non-obvious onboarding burden is the redaction policy and the on-call playbook for "why is log volume up" — both should be written before enablement.

TPM recommendation. Do not adopt as a runtime dependency. Use it as a design input to build a first-party, flag-gated, redaction-safe SQL logging capability in the Laravel stack; the high opportunity score points at a genuine gap, but the 0.105 health score says the artifact is not the answer.