Postgresql Distinct On Laravel Package

Product Decisions This Supports

• Feature decisions: It enables one recurring query shape — "latest record per group" — directly in the database: most recent order per customer, last event per device, current price per SKU, latest status per subscription. These requests show up constantly in dashboards, activity feeds, admin tables, notification digests, and API resources.
• Roadmap trade-off: This lets a team ship those features without schema changes or a denormalized current_* table maintained by triggers/jobs. It reduces the pressure to add materialized "latest" tables early, which are expensive to reverse.
• Build vs buy: It's a thin query-builder/grammar extension. The real decision is not "can we build this" (a ~50-line macro plus tests) but "do we want to own a dependency for it." Low absolute cost either way; the differentiator is maintenance ownership.
• Use cases it unblocks: paginated admin tables sorted by recency per entity; feeds collapsed to one row per actor; billing/invoice reconciliation views; reporting/export endpoints; API resources needing one "headline" child row without loading an entire relation.
• Stack strategy signal: DISTINCT ON is Postgres-only. Adopting it effectively hardens the commitment to Postgres as the sole supported database and makes MySQL portability a future migration cost rather than a free option.

When to Consider This Package

Consider it when:

• Production is PostgreSQL and will remain so; there is no multi-database requirement in the product strategy.
• The team is on Laravel 5–8 and wants DISTINCT ON without raw SQL strings scattered through the codebase.
• Queries get composed dynamically (filters, sorts, pagination), where a grammar extension is safer than hand-written selectRaw('DISTINCT ON (...)') — especially because Laravel wraps queries for count() in pagination, which breaks naive raw-prefix hacks.
• The alternative is materially worse: N+1 queries, whereIn plus per-group lookups, or a nightly rebuild of a "latest" table.

Look elsewhere or do not adopt when:

• You need Laravel 9+. The package declares 5–8, and Laravel 9 shipped in February 2022 — expect either to verify compatibility yourself or to fork.
• You need database portability. Use ROW_NUMBER() OVER (PARTITION BY ...) instead: portable, supported by Postgres, and self-owned.
• Your team already has a query-builder macro convention. A small in-house macro with tests is cheaper to own than a dependency with zero stars, zero dependents, and a Bitbucket-only home.
• The grouping key is high-cardinality with deep pagination — DISTINCT ON still sorts the full candidate set; a materialized view or keyset pagination design is a better fit.
• License/security review is strict. Single maintainer, no dependents, and no community backstop means unverifiable provenance and no external bug-fix pressure.

How to Pitch It (Stakeholders)

Executives: This is a small, targeted capability that lets us build "latest per customer/account/device" views in the database instead of in application code. It cuts database round-trips and page latency for a common class of screen — dashboards, admin lists, activity feeds — and costs essentially nothing to adopt: no vendor contract, no infrastructure change, no schema migration. The trade-off is a low-maintenance open-source dependency. We mitigate by pinning the version, covering it with our own tests, and keeping the option to vendor the roughly 50 lines ourselves. Recommendation: adopt as a scoped utility, not a platform-level dependency.

Engineering: It's a query-builder and grammar extension adding distinctOn() for Postgres, keeping queries composable with orderBy, pagination, and eager loading instead of relying on raw selectRaw prefixes that break when Laravel wraps the query for count(). Constraints are clear: Postgres-only, declared support stops at Laravel 8, and there is no maintainer signal (0 stars, 0 dependents, Bitbucket-hosted). Plan: validate against our Laravel and Postgres versions, wrap it behind our own macro or repository method so call sites don't depend on the package API, add regression tests for pagination and count(), and keep a fork path open. If version support doesn't line up, the fallback is a window-function implementation of the same query — portable, self-owned, and functionally equivalent for our use cases.