Laravel Query Logger Laravel Package

Technical Evaluation

Verdict: Conditional adoption. v6.0.0 is a platform-alignment major release for Laravel 13 / PHP 8.3+, with test and CI hardening but no production logging behavior change. Laravel 12 estates must not adopt v6 and should remain on ^5.1.

Architecture fit: The package remains a Laravel-native query logging/observability utility. It fits applications that need SQL visibility for debugging, N+1 detection, slow-query thresholds, request context, exclusions, and channel routing. It is not core business logic and should remain environment-gated and optional.

Integration feasibility: Feasible only where the application is already on Laravel ^13.0 and PHP ^8.3. The major-version break is the framework/PHP requirement, not a logging API or behavior change. Composer will naturally block v6 on Laravel 12 if the constraint is correct, but teams must explicitly pin ^5.1 for Laravel 12 to avoid confusion. The 23 behavior tests and 48 assertions materially improve confidence in bindings, duration boundaries, request context, configuration, trigger sources, thresholds, exclusions, and channels.

Technical risk: Moderate-low for compatible stacks, high for incompatible ones. Key risks: Laravel 13 ecosystem maturity and transitive dependency conflicts; the known lowest-secure Symfony Translation 6.4.0 deprecation on PHP 8.4 (CI noise, not production); and the explicit exclusion of the separate SQL interpolation fix in #71. The latter needs impact assessment if SQL logs with interpolated bindings are used for security, auditing, or precise debugging.

Key questions:

• Is the target application on Laravel 13 and PHP 8.3+? If not, is a framework upgrade planned?
• Is query logging needed in production, or only local/staging?
• Does the missing #71 interpolation fix affect our log correctness or security posture?
• Which log channels, retention, exclusions, and slow-query thresholds will we standardize?
• Can we tolerate the documented Symfony Translation deprecation in lowest-secure CI graphs?
• What is the support expectation for ^5.1 on Laravel 12 while the estate remains there?

Integration Approach

Stack fit: Adopt v6 only for Laravel 13 / PHP 8.3–8.5 applications. Keep Laravel 12 applications on overtrue/laravel-query-logger:^5.1. Do not attempt to force v6 on Laravel 12. Treat the package as an observability utility, not a platform dependency.

Migration path: Inventory Laravel/PHP versions first. For Laravel 12, pin ^5.1 and defer. For Laravel 13, create a branch, require ^6.0, publish/compare configuration, set environment gates, configure thresholds/exclusions/channels, and validate in local and staging before production. Because production source and logging behavior are unchanged, the main migration work is platform compatibility and configuration hygiene, not code changes.

Compatibility: v6 requires Laravel ^13.0 and PHP ^8.3. CI covers PHP 8.3, 8.4, and 8.5 across lowest-secure, highest, and locked dependencies. Composer security blocking and audit passing reduce dependency risk. The known lowest-secure deprecation notice is a CI/autoload-order issue, not a production runtime concern. The omitted #71 interpolation fix is the main functional compatibility question.

Sequencing:

1. Classify applications by Laravel/PHP version.
2. Pin Laravel 12 apps to ^5.1; do not include v6 in their upgrade path.
3. For Laravel 13 apps, pilot v6 in non-production with explicit thresholds, exclusions, and log channels.
4. Review log output for sensitive bindings, volume, and interpolation correctness; determine whether #71 is a blocker.
5. Promote to production only if query logging is operationally useful and log volume is controlled.
6. Revisit after the next patch if #71 or dependency notices affect us.

Operational Impact

Maintenance: Low ongoing maintenance if version pins are explicit. The new tests and CI matrix improve maintainability and regression safety. Track the package’s Laravel 13 support lifecycle, the #71 interpolation fix, and the upstream Symfony Translation deprecation. Keep Composer audit and lockfile checks in CI.

Support: v6 support is effectively limited to Laravel 13 / PHP 8.3+. Laravel 12 teams remain on ^5.1, so support expectations must be split by framework version. The known upstream notice is documented but not suppressed; teams should accept it as CI noise or isolate it rather than treating it as a production defect.

Scaling: The main scaling risk is log volume. Query loggers can generate substantial I/O in high-traffic production if verbose logging is enabled. Use threshold filtering, SQL exclusions, dedicated channels, retention limits, and environment gating. Avoid using this as a replacement for APM; use it for targeted query diagnosis and regression checks.

Failure modes: Misconfiguration can cause log noise, disk pressure, or sensitive binding exposure. A too-low threshold or missing exclusions can overwhelm logs. Channel misrouting can hide useful data. Incompatible Laravel/PHP versions block installation. The missing #71 fix may produce misleading interpolated SQL in some cases. The documented deprecation can create CI noise. Define a runbook for enabling/disabling logging and rotating/retaining query logs.

Ramp-up: Low for Laravel teams. Configuration is package-native, and the expanded test coverage reduces adoption uncertainty. Ramp-up effort should focus on log format, threshold selection, exclusion rules, sensitive-data handling, and channel/retention policy. For TPM leverage, position v6 as a controlled diagnostic tool for Laravel 13 performance triage, not a default-on production feature.