Eloquent Percentile Laravel Package

Technical Evaluation

• Architecture fit: abordage/eloquent-percentile extends Eloquent with percentile aggregate query methods (e.g., p50/p90/p95 on model columns). It fits Laravel applications that need lightweight in-app analytics without introducing a separate OLAP store. The package is a thin query-layer addition, not a service or infrastructure dependency.
• Integration feasibility: Composer-installable Laravel package. Release 2.1.0 adds Laravel 13 support and removes Laravel 11 from the CI test matrix. Dependabot bumps in this release are CI-only and have no runtime impact. Feasibility hinges on database support, since percentile functions are DB-specific; CI references Postgres setup, so Postgres is likely the primary tested target. Validate PHP version constraints and DB driver support before committing.
• Technical risk: Moderate. Dropping Laravel 11 testing does not necessarily break L11, but it means L11 compatibility is no longer guaranteed by CI. Database portability is the larger risk: native percentile functions differ across Postgres, MySQL, and SQLite, and emulation may have performance or correctness trade-offs. Additional risks include null handling, ties, column-name interpolation/security, and query cost on large tables.
• Key questions: Which PHP and Laravel versions are officially supported in 2.1.0? Which databases are tested and supported? Does “stop testing Laravel 11” mean L11 still works but is unsupported, or is it effectively dropped? Are percentile calculations exact or approximate? How are nulls and duplicate values handled? Are column names validated to prevent SQL injection? What is the query plan/performance on large datasets, and does it use indexes?

Integration Approach

• Stack fit: Best fit for Laravel 12/13 applications, especially those on Postgres, that need percentile reporting inside existing Eloquent workflows. Less attractive for multi-database products unless the package’s DB support matrix matches the product’s supported databases.
• Migration path: From 2.0.x to 2.1.0 is a minor release. Applications on Laravel 13 can adopt 2.1.0 directly after staging validation. Applications still on Laravel 11 should either remain on 2.0.x or treat 2.1.0 as untested on L11 and require explicit regression testing before upgrade.
• Compatibility: Confirm PHP version, Laravel version, and database driver compatibility. The release explicitly adds Laravel 13 and removes Laravel 11 from CI; plan around that support boundary. Dependabot changes are non-functional for package consumers.
• Sequencing: 1) Inventory Laravel/PHP/DB versions across services. 2) Trial 2.1.0 in a branch with representative data. 3) Validate percentile outputs against known SQL results, including nulls and ties. 4) Introduce in low-risk reporting or admin analytics first. 5) Benchmark query latency and database load before expanding to user-facing or high-QPS paths.

Operational Impact

• Maintenance: Low runtime surface area, but the package is OSS and depends on maintainer cadence. The 2.1.0 release shows active CI maintenance and dependency hygiene. Pin versions in composer.json and review changelogs for Laravel support changes.
• Support: Community-supported; no vendor SLA. Internal teams should document supported Laravel/DB combinations and provide example queries. Escalation for incorrect percentile results will likely require SQL and database expertise.
• Scaling: Percentile queries can be expensive on large tables because they often require sorting or full scans. Use indexes where possible, pre-aggregate or materialize percentile results for dashboards, and avoid calling percentile queries in high-frequency request paths. Treat this as an analytics convenience, not a real-time aggregation engine.
• Failure modes: Missing database percentile functions, SQL errors from unsupported drivers, incorrect results due to null/ties handling, performance regressions on large datasets, and Laravel version incompatibility after the L11 test removal. CI-only dependency bumps in 2.1.0 are not expected to cause runtime failures.
• Ramp-up: Low for Laravel developers familiar with Eloquent; moderate for teams needing to reason about SQL percentile semantics and database performance. Provide guardrails: supported versions, approved databases, example queries, and performance limits.