Pinba Bundle Laravel Package

Product Decisions This Supports

• Instrumentation scope: which layer gets optimized first. The bundle emits per-operation timers for Doctrine queries, Twig rendering, and Memcache calls. That turns "the page is slow" into a ranked list — DB vs. templating vs. cache — which is the evidence you need to sequence performance work on the roadmap instead of guessing.
• Build vs. buy on APM. If the data you actually act on is "p95 time per subsystem," a self-hosted Pinba server plus this bundle delivers it without per-host SaaS APM seats. The decision this supports is whether to fund a commercial observability contract or a one-time integration plus an ops-owned daemon.
• Performance budget / SLO definition. Because timers are cheap and always-on (UDP to a stats daemon), you can define budgets like "Twig render < 40ms p95" and treat breaches as regressions. That's a product decision about acceptable latency, backed by continuous data rather than ad-hoc profiling.
• Legacy observability modernization. Adopting or rejecting this package is itself the fork in the road: stay on the Pinba path (niche, self-hosted, low cost) or invest in OpenTelemetry / Blackfire / Tideways (broader, distributed, higher cost and effort). Committing here means explicitly deferring the migration.
• Cost of ownership vs. feature gap. With 22 stars, zero dependents, and a single-maintainer profile, the PM decision is "acceptable risk for an internal tool with an exit path" rather than "strategic platform dependency." Score/opportunity signal says the gap is real but the ecosystem around it is thin.

When to Consider This Package

Adopt when:

• You already run a Pinba server and the PHP pinba extension (or are willing to own them). Without that daemon, this package has nothing to talk to.
• The application is Symfony-based, or you accept a port: the bundle is Symfony DI/service-tagging, and Doctrine-centric. On Laravel/Symfony-mixed stacks, Eloquent has no equivalent instrumentation here — you'd write the query listener yourself.
• You need layer-level timing, not distributed traces, and the app is effectively single-service.
• Self-hosting is mandatory (regulated, air-gapped, or no-SaaS-egress environments) and the budget for APM seats is zero.
• You want a cheap always-on baseline alongside targeted deep profiling, not a replacement for it.

Look elsewhere when:

• You need cross-service tracing, call graphs, or flame graphs — use OpenTelemetry plus Blackfire/Tideways/SPX.
• You want Laravel-native instrumentation — Laravel Pulse or Telescope covers cache/query/job timing with first-party support.
• Maintenance guarantees matter. Zero dependents and a small star count mean you should assume you are the maintainer; a security or PHP-version break is yours to fix.
• Your MySQL is managed/cloud and you cannot install the Pinba storage engine, or your MySQL version has dropped the engine.
• You need sampling, alerting, and retention — Pinba is a raw stats sink; dashboards and alerting are your build.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, self-hosted instrumentation option that gives us per-layer timing — database, templating, cache — without buying APM seats per host. The trade-off is maturity: it's a small, single-maintainer package built around a niche statistics daemon. Recommendation is a time-boxed spike (1–2 engineer-days) behind a flag, with a documented exit path to OpenTelemetry if it doesn't pay for itself. Do not treat it as a platform commitment.

To engineering: Integration is small — a bundle that registers timers around Doctrine, Twig, and Memcache, with near-zero request overhead since reporting is fire-and-forget UDP. Hard requirements are the pinba PHP extension and a Pinba-enabled MySQL instance, both of which we own operationally. On Laravel, expect extra work: the Doctrine listener has no direct equivalent, so query timing needs a custom listener, roughly doubling the integration estimate. Flag the maintenance risk explicitly — assume we fork if upstream stalls.