Laravel Dump Sql Laravel Package

Product Decisions This Supports

• Developer-productivity investment: This is internal DX tooling, not a customer-facing feature. It supports the recurring decision of how much to invest in debugging ergonomics for the data layer, where a large share of Laravel incident time is spent reconstructing "what SQL actually ran."
• Build vs. buy vs. framework-native: Informs whether to write and maintain an in-house SQL-formatting helper, adopt a tiny package, or rely on Laravel's own toRawSql()/ddRawSql() (available in Laravel 10.x+/11+). The decision hinges on your Laravel version and how much you value the dumpSql()/ddSql() macro ergonomics over framework-native parity.
• Tooling stack consolidation: Helps decide whether this belongs alongside — or replaces part of — heavier observability investments like Laravel Telescope, Debugbar, Ray, or Pulse. This package is a point-in-time inspection tool (tinker, artisan commands, a breakpoint); it is not a query profiler, aggregator, or production monitor.
• Support and escalation workflow: Supports decisions about how engineers reproduce customer-reported data issues. Copy-pasteable SQL with bindings inlined shortens the loop between "report" and "reproducible query," which is a measurable MTTR lever for support engineering.
• Test and CI ergonomics: Supports decisions on asserting against generated SQL in feature tests, and on debugging failing test suites without attaching a debugger.
• Risk posture for dev-only dependencies: A 36-star, single-maintainer MIT package with a last release in March 2024 is a legitimate dev-only bet — it feeds a decision to allow low-ceremony dependencies in require-dev while holding production dependencies to a stricter bar.

Use cases: tinker exploration, artisanal one-off scripts, onboarding engineers to an unfamiliar schema, debugging queued jobs and raw query builder code, and reproducing Eloquent-generated SQL during code review.

When to Consider This Package

Consider it when:

• You are on a Laravel version where toSql() still returns ? placeholders and you want bindings inlined without hand-interpolating.
• Your team lives in tinker, artisan commands, and test suites and wants a zero-infrastructure, no-UI, no-service way to eyeball the real SQL.
• You want the ergonomics of dumpSql()/ddSql() macros on the query builder inside an existing Laravel app rather than a separate debugging service.
• Your dependency policy tolerates a small, MIT-licensed, single-maintainer package in require-dev only.

Look elsewhere when:

• You are on Laravel 11+ and native toRawSql()/ddRawSql() already covers the need — adoption cost likely exceeds the marginal benefit.
• You need profiling, query aggregation, N+1 detection, timeline correlation, or production-safe sampling — use Telescope, Debugbar, Pulse, or an APM.
• You require vendor SLAs, security review of every dependency, or long-term maintenance guarantees; a 36-star project with a solo maintainer and a 2024 release is a continuity risk you should consciously accept or reject.
• Security/compliance is a hard gate: inlining bindings means real values — potentially PII or secrets — land in logs, terminal scrollback, and CI output. If your policy forbids that even locally, do not adopt, or wrap it behind an explicit local-only guard.
• You need a cross-language or vendor-neutral SQL inspection story; this is PHP/Laravel-specific by design.

How to Pitch It (Stakeholders)

For executives: A free, MIT-licensed, developer-only utility that lets engineers see the exact SQL their application sends to the database — complete, with values filled in — instead of a placeholder-filled approximation. It costs nothing to license, requires no infrastructure, and never ships to production; it is installed as a development dependency only. The business value is time: faster debugging of data bugs, faster reproduction of customer-reported issues, and faster onboarding onto an unfamiliar schema. The risk is equally small and bounded — one small third-party package, confined to development and testing environments, with no runtime exposure to customers. Recommendation: trial it on one team, keep it out of production dependencies, and revisit if the framework's built-in equivalent makes it redundant.

For engineering: composer require --dev guanguans/laravel-dump-sql, then ->dumpSql() / ->ddSql() on the query builder in tinker, a command, or a test. It saves the manual ?-to-binding interpolation step and the "add DB::listen and dump" ritual. Two caveats: (1) it overlaps with Laravel's native toRawSql(), so check your version before adding a dependency; (2) inlined bindings mean real data in output — keep it local, never in shared CI logs or production, and pin the version since the project is small and lightly maintained. If you already run Telescope or Debugbar, treat this as a scratchpad, not a replacement for profiler-grade observability.