Pgsql Doctrine Random Function Laravel Package

Product Decisions This Supports

• Randomized content/serving features: any DQL query that needs ORDER BY RANDOM() — "random item of the day," shuffled quiz questions, random promo/coupon assignment, randomized onboarding samples, lottery/giveaway draws, A/B bucketing at the query layer, and "discover" or "surprise me" surfaces.
• Build vs. buy (really: buy vs. vendor): the capability is a single DQL function class. The decision is not whether to build something complex, but whether to take a 3-star, 0-dependent dependency versus copying ~30 lines into your own App\Doctrine\Functions namespace. For most teams, the correct PM call is "reimplement in-house, use the package as reference."
• Architecture/roadmap signal: adopting this is an explicit commitment that (a) you run Doctrine ORM rather than Eloquent, and (b) PostgreSQL is a hard requirement, not a preference. That constrains future database-portability and hosting decisions — worth surfacing before it hardens.
• Where it belongs in the roadmap: a tactical enabler for a small feature, not a platform investment. It should be scoped to a specific ticket ("random selection on X") rather than adopted as shared infrastructure.
• What it does not decide: it does not solve randomization at scale. ORDER BY RANDOM() forces a full table scan and sort; on any large table this is a performance decision, not a library decision.

When to Consider This Package

Consider it when:

• Your stack is Doctrine ORM + PostgreSQL (note: Doctrine is not Laravel's default — this implies laravel-doctrine/orm or a Symfony/standalone Doctrine app).
• You specifically want RANDOM() available inside DQL, so repositories avoid raw SQL and stay testable/composable.
• The random selection operates on small-to-moderate result sets where a full scan is acceptable, or is bounded by additional WHERE filters.
• You want a reference implementation to copy rather than a dependency to install.

Look elsewhere (or don't adopt) when:

• You use Eloquent: Laravel's inRandomOrder() already does this; the package is irrelevant.
• You are on MySQL, MariaDB, or SQLite — the function is Postgres-specific.
• You need seeded/deterministic randomness (reproducible tests, consistent shuffles per user), which RANDOM() does not provide.
• Your tables are large: you need keyset/tablesample strategies (TABLESAMPLE SYSTEM, random-offset pagination, or precomputed random columns), not a DQL function.
• You require active maintenance and security posture: 3 stars, 0 dependents, and a narrow surface area mean there is effectively no community signal. Treat it as unmaintained code you are adopting.

How to Pitch It (Stakeholders)

To executives: This is a small, free (MIT) utility that unblocks a specific class of "randomized" product features — random picks, shuffles, and draws — for teams running PostgreSQL with Doctrine. It carries no license cost and no data/security exposure beyond reading your own database. The real risk is bus factor: three GitHub stars and zero downstream dependents mean nobody is watching it. Recommendation is to use it as a pattern to copy, not a dependency to install, which gives us the capability with no supply-chain exposure and no upgrade treadmill.

To engineering: One DQL function registration that teaches Doctrine about Postgres RANDOM(), letting you write ORDER BY RANDOM() in DQL instead of dropping to native SQL in repositories. It's roughly a single class — vendoring it into our own Doctrine\Functions namespace costs an afternoon and removes an unmaintained third-party from composer.json. Flag: the underlying SQL is ORDER BY RANDOM(), which is a full scan and sort; fine for filtered or small sets, a trap on large tables. If the feature is "random selection over the whole catalog," we should discuss TABLESAMPLE or a precomputed random-key column instead. Also worth an explicit decision: this only makes sense if we've committed to Doctrine + PostgreSQL, since Eloquent users already have inRandomOrder().