To Raw Sql Laravel Package

Product Decisions This Supports

• Build vs. buy (lean "adopt"): The package is a thin utility that converts Laravel Query/Eloquent builders into a fully interpolated SQL string (bindings inlined, not ? placeholders). The real decision isn't buy vs. build — it's whether to standardize a small internal debugging helper or take a 1-file dependency. Either way the cost is trivial; this is a low-stakes, reversible call.
• Developer-experience roadmap: Justifies investment in a "reproducible bug report" capability — support tickets and incident channels get a copy-pasteable query instead of a builder dump. Informs whether raw SQL belongs in exception context, admin/debug panels, or a php artisan diagnostic command.
• Support & incident tooling: Enables a decision to ship a first-class "give us the SQL" path for L2 support and for reproducing data bugs without DB access. Measures whether mean-time-to-diagnose improves.
• Query review and performance workflow: Makes it cheap to hand a DBA or platform team the exact statement behind a slow endpoint, supporting decisions about indexing, N+1 fixes, and query-budget standards.
• Internal starter kit / template decision: A candidate inclusion for the team's Laravel scaffolding — as an opt-in dev-only dependency, not a production service dependency.
• Logging policy decision: Forces an explicit decision on what gets logged. Inlined SQL contains literal values, so this surfaces the PII/secret-redaction question in query logging, which is a product/compliance decision, not just a technical one.
• Not supported: production observability strategy, APM, or slow-query monitoring. Those need DB::listen, Telescope, Debugbar, or an APM vendor — this package is a formatting convenience, not instrumentation.

When to Consider This Package

Adopt when:

• The stack is Laravel and the need is human-readable SQL for humans — bug reports, code review, support handoffs, documentation, one-off data exports.
• The team is small, the package would be wrapped behind an internal helper/interface, and you're comfortable pinning a single version.
• Volume is low: dev-only or on-demand diagnostics, not per-request production logging.

Look elsewhere (or write a ~20-line helper) when:

• Maintenance signal is a blocker. 56 stars, 0 dependents, sole maintainer, last release July 2023 — treat it as effectively unmaintained. Verify compatibility with your Laravel version before betting on it; if it's stale, a local helper is strictly better.
• You need production-grade query observability. Use Laravel's query log / DB::listen, Telescope, Debugbar, or an APM tool instead.
• You need safe or auditable query logging. Inlining bindings puts literal values (emails, tokens, payment data) into logs. If you need durable logging, prefer parameterized logging with a redaction layer.
• Security posture is strict. An unmaintained third-party package in the request path expands supply-chain surface for near-zero functional gain.
• You need dialect-specific or fully optimized SQL — interpolated output is for reading, not for execution or benchmarking.

How to Pitch It (Stakeholders)

To executives: A free, MIT-licensed, tiny utility that turns Laravel's internal query objects into plain SQL anyone can read. It's a developer-productivity shortcut that shortens bug triage and support cycles, with essentially no cost and no vendor lock-in. The caveat is that it's a small, single-maintainer project with no recent releases — so we'd use it as an internal convenience, wrap it behind our own code, and treat it as replaceable in an afternoon. Low value, low risk, low commitment.

To engineering: One dependency, one method call: get interpolated SQL from any Query or Eloquent builder for debugging, error context, and support tickets. Trade-off is explicit — the output is for humans, not execution; it inlines bindings so it must never be dumped into persistent logs containing PII without redaction; and the package hasn't shipped since mid-2023 with no dependents, so we pin the version and isolate it behind our own SqlFormatter-style interface. If the API surface or Laravel compatibility doesn't hold, we swap in a local helper with no caller changes.