- What does overtrue/laravel-query-logger do?
- It is a Laravel dev tool that records every SQL query your application runs, including the bound parameters and execution time. It writes readable log entries that make debugging and performance analysis easier during local development. It also highlights slow and duplicate queries, which helps you spot N+1 patterns and other inefficiencies with almost no setup.
- How do I install overtrue/laravel-query-logger in a Laravel app?
- Install it with Composer using composer require overtrue/laravel-query-logger. For Laravel 13 and PHP 8.3 or newer, use version ^6.0. For Laravel 12 applications, pin ^5.1 instead, because v6 is a platform-alignment major release that requires the newer framework and PHP versions.
- Does laravel-query-logger support Laravel 12?
- Laravel 12 is supported on the ^5.1 release line, not on v6. Version 6.0.0 targets Laravel ^13.0 and PHP ^8.3+, so Composer will block it on a Laravel 12 application if constraints are declared correctly. Teams staying on Laravel 12 should explicitly pin ^5.1 to avoid confusion during upgrades.
- Which Laravel and PHP versions are required for v6 of laravel-query-logger?
- Version 6 requires Laravel ^13.0 and PHP ^8.3. The CI matrix covers PHP 8.3, 8.4, and 8.5 across lowest-secure, highest, and locked dependency graphs. The major-version break is the framework and PHP requirement, not a change to the logging API or runtime behavior.
- Can laravel-query-logger detect slow queries and N+1 problems?
- Yes, the package highlights slow queries against configurable thresholds and flags duplicate queries. Duplicate query detection is useful for finding N+1 patterns where the same SQL statement runs repeatedly inside a loop. You can review the log output during local development and then refactor the offending code with eager loading or query optimization.
- How do I configure log channels, thresholds, and query exclusions?
- The package is configured through a published Laravel config file where you set the log channel, slow-query threshold, and any query exclusions. Publish and review the configuration on each environment rather than relying on defaults. In the v6 migration, the main work is configuration hygiene plus environment gating, since production source and logging behavior are unchanged.
- Should I enable laravel-query-logger in production?
- It is intended as a development and staging observability utility, so keep it environment-gated rather than always on. If you do enable it in production, review log volume, retention, and whether sensitive bindings appear in the output. Define which channels and exclusions you will standardize before promoting it beyond local environments.
- Is laravel-query-logger well tested and safe to adopt?
- Version 6.0.0 includes 23 behavior tests with 48 assertions covering bindings, duration boundaries, request context, configuration, trigger sources, thresholds, exclusions, and channels. CI runs across PHP 8.3 to 8.5 on lowest-secure, highest, and locked dependencies. The overall risk is moderate-low on compatible stacks and high on incompatible ones, so version fit is the key decision.
- What are the known risks or issues with laravel-query-logger v6?
- The main risks are Laravel 13 ecosystem maturity and transitive dependency conflicts, plus a known Symfony Translation 6.4.0 deprecation on PHP 8.4 that affects lowest-secure CI graphs rather than production runtime. The package also explicitly excludes the separate SQL interpolation fix from issue #71. If you rely on interpolated bindings for security, auditing, or precise debugging, assess that omission before adopting.
- How does laravel-query-logger compare to Laravel Telescope or Debugbar?
- Telescope and Debugbar are broader debugging suites, while this package focuses narrowly on SQL query logging with bindings, timing, slow-query thresholds, duplicate detection, request context, and channel routing. That makes it lightweight and easy to drop into an existing Laravel app when you only need query visibility. Choose it as an observability utility rather than a platform dependency, and keep it optional and environment-gated.