Db Profiler Laravel Package

Product Decisions This Supports

• Performance roadmap triage. Profiling query volume and time inside Artisan commands, scheduled jobs, and queue workers lets you separate "the database is slow" from "the code is doing too many round trips" before you commit a sprint to caching, indexing, or a read replica. This is the package's main differentiator: most profiling tools only see HTTP requests, so the cron/queue tier — usually where batch jobs quietly burn minutes — is invisible.
• Build vs. buy for internal tooling. The alternative here is a homegrown DB::listen() logger with a hand-rolled console table. That's typically 1–3 engineer-days plus indefinite maintenance. Adopting a dev-only package is usually the cheaper call, and the exit cost is one line in composer.json.
• Acceptance criteria for optimization work. "Query count for the nightly import drops from 4,200 to under 400" is a testable story-level outcome. A profiler that works in console makes that a before/after measurement instead of a guess, which tightens estimates on future perf work.
• Support and incident diagnosis. Onboarding engineers and support staff to "why is this job slow / why did it time out" gets a one-command answer rather than an hour of dd() and log spelunking. Measurable as reduced time-to-diagnose on a class of tickets.
• Observability spend decisions. A free, local, zero-infrastructure profiler answers the dev-time question cheaply. That informs whether the paid APM tier (Datadog, Sentry Performance, New Relic) is justified for production, or whether Laravel Pulse covers the ops side — you buy the expensive thing only for the questions this can't answer.
• Feature scoping. If a feature's cost is dominated by per-item queries in a loop, that's a design conversation (eager loading, chunking, batching) rather than a hardware conversation — worth knowing before you commit to the estimate.

When to Consider This Package

Adopt when most of the following hold:

• Your workloads are console-heavy. Scheduled commands, queue workers, importers, and reporting jobs are a meaningful share of your runtime. This is the strongest adoption signal; it's precisely the gap where Debugbar and similar tools stop working.
• You want zero infrastructure. No extra database, no migrations, no storage growth, no config file, no production service to run. Enablement is opt-in and per-request/per-command.
• You need an opt-in switch, not always-on. Middleware or a programmatic toggle means you profile one route or one command on demand rather than paying overhead across everything.
• The team is on Laravel/PHP and comfortable with dev-only Composer dependencies. Low friction; no new mental model.
• You want a stopgap while Telescope/Pulse is evaluated. A one-day spike is cheap and gives you real query data to size the bigger tooling decision.

Look elsewhere when:

• You need production profiling or alerting. This is a development diagnostic, not an APM. Use Laravel Pulse, Telescope in a dedicated environment, or a hosted APM for live traffic, uptime, and alerting.
• You need N+1 detection enforced in CI. A regression guard (e.g., a query-count assertion in the test suite, or Spatie's query detector) covers what a manual profiler cannot: preventing the regression before merge.
• You need cross-service tracing or distributed context. Request-scoped DB profiling doesn't follow a call across services.
• You need a vendor SLA, security review, or commercial support. Single-maintainer, MIT, modest adoption — fine for a dev dependency, wrong for anything auditors will ask about.
• Non-engineers need the output. There's no dashboard for stakeholders; the value is entirely in the engineer's terminal or browser session.
• Your profiling need is HTTP-first and shallow. Laravel Debugbar already covers that with a richer panel set, so adding a second tool is net complexity.

Two risk notes to weigh honestly: the project has a small maintainer footprint and near-zero downstream dependents, so treat version pinning and a "remove in one commit" posture as prerequisites rather than optional hygiene. The upside is that because it's dev-only, a failure mode is a broken local tool, never a production incident — which is what makes the low social proof tolerable.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a free, MIT-licensed diagnostic tool that installs only on developer machines and never touches production. It answers a question we currently pay engineers to answer by hand: which of our scheduled jobs and background tasks are slow because of the database. The business case is time-to-diagnose and better estimates on performance work, not new revenue — so the right framing is a small, reversible engineering-efficiency bet, not a platform investment. Cost is effectively one engineer-day to trial; downside risk is near zero because the dependency is dev-only and removable in a single commit. Recommend a timeboxed trial on our two heaviest scheduled jobs, with a decision gate: if it shortens diagnosis on those jobs, standardize it in the dev setup; if not, drop it and revisit the APM question with the data we collected.

For engineering leadership: One --dev Composer dependency, no config, no migrations, no storage. It hooks the HTTP pipeline via middleware and console commands via a listener, giving a query table with count, timing, and the calling context. Its distinguishing feature is console support — cron and queue profiling — which is the layer our existing tools don't cover. Overhead is opt-in and scoped, so it can't leak into a normal request path. Pin the version; the maintainer is a single person with limited downstream adoption, so we should assume we may need to vendor it or replace it with a 50-line DB::listen() implementation if it stalls.

For the team: Use it to produce numbers for perf tickets, not as a permanent always-on fixture. Complement it — don't replace — with a CI query-count guard so regressions are caught before merge, and with Pulse or an APM for production visibility. One rule: profiler output is evidence in a ticket, not a deliverable, and it should never be enabled in a shared or production environment.