Eloquent Percentile Laravel Package

Product Decisions This Supports

• Feature scoping for analytics-style surfaces: percentile calculations (p50/p90/p95/p99) on top of existing Eloquent models let you ship "typical vs. tail" metrics — response times, order values, session lengths, scoring distributions — without standing up a separate analytics store. This directly informs whether a metric belongs in-product, in a dashboard, or in a data warehouse.
• Build vs. buy vs. borrow: this package is a "borrow" — a narrow, single-purpose query helper. It replaces a custom SQL/aggregation layer for a well-understood statistical operation, so engineering time goes to the product surface rather than to percentile math and database-dialect edge cases.
• Roadmap signal — platform currency: release 2.1.0 adds Laravel 13 support and stops testing on Laravel 11. That tells you the maintainer tracks the framework's release cadence, which matters when you're planning an upgrade window and deciding which third-party packages can ride along.
• Use cases that fit cleanly: SLA/uptime reporting, pricing and discount-distribution analysis, cohort performance comparisons, fraud or anomaly thresholds expressed as "above the 95th percentile," and internal admin reporting where an approximate-but-cheap aggregate beats a full BI pipeline.
• Use cases that don't: anything requiring statistically rigorous streaming approximations at very large scale, multi-source joins across warehouses, or user-facing exports of raw distributions — those warrant a dedicated analytics tool.

When to Consider This Package

Adopt when:

• Your data already lives in a relational database behind Eloquent, and the percentile call sits on a model you own (no cross-database or federated queries).
• You need a handful of percentile metrics, not a metrics platform — the value is in avoiding a bespoke implementation, not in breadth.
• You are on Laravel 12 or 13. Laravel 13 is now explicitly supported; Laravel 11 is no longer in the test matrix, so treat it as unverified and plan your upgrade accordingly.
• The team values small, single-responsibility dependencies with automated dependency hygiene — the 2.1.0 changes are almost entirely CI/dependency bumps, which is a healthy maintenance signal rather than a feature signal.

Look elsewhere when:

• You need windowed/streaming percentiles over high-volume event streams, histograms with arbitrary bucket configuration, or approximate quantile sketches (t-digest, HLL) — reach for a purpose-built analytics library or your warehouse's native functions.
• You require guaranteed semantic-versioning guarantees around database dialect support; the release notes give no indication of dialect coverage changes, so validate against your engine (MySQL, PostgreSQL, SQLite) before committing.
• You are pinned to Laravel 11 and cannot upgrade — this release does not help you, and future releases will drift further from your version.
• Percentiles are a one-off: a single raw SQL query is cheaper than a dependency.

Practical adoption checklist: confirm the supported Laravel/PHP matrix against your runtime, run the package's queries against a production-shaped dataset to check index usage and query plans, and verify behavior on the specific database engine you deploy.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk library that lets the team add "typical vs. worst-case" performance metrics to the product without building or buying an analytics platform. The latest release is a maintenance release — the substantive change is that it now supports the newest Laravel version, which keeps our upgrade path clear. Cost is negligible; the benefit is avoided engineering spend on a solved statistical problem.

For engineering: abordage/eloquent-percentile provides percentile aggregates directly on Eloquent models, removing the need for hand-rolled SQL. Version 2.1.0 adds Laravel 13 support and drops Laravel 11 from CI; the remaining changes are Dependabot bumps to GitHub Actions and fetch-metadata. No breaking API changes are described in the notes, but the Laravel 11 test coverage removal should be treated as a de facto support boundary — confirm your target version before adopting, and verify query plans on your database engine since percentile computation can be index-sensitive at scale.

Recommended action: approve for evaluation in a non-critical reporting path; treat as low-priority to adopt unless a percentile feature is already on the roadmap.