Product Decisions This Supports
- Build vs. buy for Postgres-heavy back ends. If your product logic already lives (or should live) in database functions — reporting aggregates, ranking/search scoring, multi-tenant row filtering, heavy joins — this package is a ~200-line reference for a thin, testable PHP seam over
select * from fn(...). It supports the decision "keep logic in the DB, but stop calling it through ad-hoc DB::select() strings scattered across controllers."
- Feature scoping and release decoupling. Function-backed features (analytics endpoints, dashboards, scoring) can ship without an ORM modeling exercise, and SQL functions can be tuned/redeployed independently of PHP releases. Useful when a roadmap item is blocked on "we don't have an Eloquent model for this."
- Architecture standardization. It codifies a convention — one repository class per function/namespace, typed inputs, casted outputs — which gives code review something to point at and gives tests something to mock. That's a process decision more than a technical one.
- Testability and environment parity. A repository boundary means feature tests can fake the function layer instead of requiring a fully seeded Postgres instance, which affects how you scope CI and local dev setup.
- Explicitly not a differentiator. No roadmap item should be gated on this package. It is a pattern to internalize, not a platform bet.
When to Consider This Package
Consider adopting the pattern (copy it into your app) when:
- PostgreSQL is your primary and durable datastore, and that isn't changing this planning cycle.
- You already have meaningful logic in stored functions, or a credible plan to put it there (analytics, geospatial, full-text ranking).
- Your team is small enough that owning ~200 lines of PHP plus tests is cheaper than designing the abstraction from scratch.
- You want the convention more than the code — a documented "all SQL function calls go through a repository class" rule.
Look elsewhere / do not adopt as a dependency when:
- You need a supported dependency. The 1.1.2 patch adds explicit Laravel 10 support (a positive signal on compatibility), but the package still has a single maintainer, ~7 stars, 0 dependents, and no stated security policy or issue-triage cadence. There is no SLA and no compatibility guarantee beyond what has been tagged. Treat the source as reference material and vendor it under your own tests.
- Any non-Postgres target. MySQL/SQLite/multi-database products get nothing here.
- Your engineering policy discourages DB-side logic. Then the correct answer is Eloquent scopes, query objects, or database views — not a function repository.
- You need typed DTO hydration, connection pooling, read/write splitting, or observability hooks at scale. That's an in-house abstraction with a real owner.
- You need an SLA, vendor accountability, or a compliance story. MIT license removes legal friction, not operational risk. Laravel 10 support does not change the bus-factor-1 reality.
Verify the actual API surface, supported Laravel/PHP matrix, and test coverage against your stack before committing — a single patch release is not evidence of an ongoing maintenance commitment, so you remain the compatibility test.
How to Pitch It (Stakeholders)
To executives: This is a small, MIT-licensed pattern for calling PostgreSQL functions cleanly from our Laravel code — no license cost, no vendor lock-in, no new infrastructure. It is not a dependency we should take on: it is a single-maintainer project with no support commitment, so the recommendation is to internalize the pattern (roughly a day of engineering plus tests) rather than install it. The 1.1.2 release added Laravel 10 support, which is encouraging, but it doesn't change the ownership calculus. Net effect: cleaner, more testable code around database-side logic, with the maintenance risk absorbed internally and contained.
To engineering: One class per SQL function, typed inputs, predictable result casting, and a boundary you can mock in feature tests. It replaces free-floating DB::select() calls with a reviewable convention. 1.1.2 is a compatibility patch (Laravel 10 tag) with no API changes, so it does not alter the integration shape. Caveat is explicit: we own the code, we write the tests, we track Laravel upgrade compatibility ourselves. Recommended path is to fork/vendor the approach behind our own interface, add coverage, and gate access through a service container binding so swapping the implementation later is a one-file change.