Perpl Laravel Package

Technical Evaluation

Architecture fit

• Perpl is a maintained fork of Propel2: a schema-first ORM where models are generated from an XML schema into base classes, with its own connection/runtime layer and its own query API. This is architecturally orthogonal to Laravel, which is Eloquent-centric and container/event driven.
• In a Laravel application, adopting Perpl means deliberately running a second, non-native persistence layer. You lose Eloquent model events, factories, policies, attribute casting, artisan make:model, and the broad ecosystem that assumes Eloquent models (Filament, Nova, Telescope model insights, most Spatie packages).
• Genuine fit exists in exactly two cases: (a) an existing Propel2 codebase being incrementally moved onto Laravel, or (b) a Laravel app that must share a schema and query semantics with a system already on Propel and wants a single ORM rather than two. For greenfield Laravel work, this is a lateral move with negative ecosystem value.
• With 26 stars and an "opportunity" score of 2.23, treat this as a niche, single-maintainer-scale dependency until proven otherwise. The unknown repository field is itself a provenance finding — you cannot complete a supply-chain review from the package metadata alone.

Integration feasibility

• Technically feasible: a service provider can bootstrap Propel's runtime configuration and expose generated models to the container. There is no first-party Laravel integration package, so the glue is yours to own and maintain.
• Code generation sits outside the artisan lifecycle (composer scripts or a custom command), which creates a second, parallel "schema toolchain" alongside Laravel migrations. Decide up front which one is authoritative — running both against one database is a drift generator.
• Dual-ORM operation is the sharp edge. Two connection pools, two identity maps, and two notions of transaction scope mean a transaction begun through DB:: will not roll back Perpl writes and vice versa. Any code path touching both is a correctness risk, not a performance one.
• PHP/Laravel version compatibility is unverified and must be a gating question. Current Laravel releases require PHP 8.2+, and the fork's CI matrix is not visible from the package metadata.

Technical risk

• Bus factor and longevity: a fork of a stagnating upstream, small contributor base, and a recent release date that demonstrates a release but not a cadence. The failure mode is being stranded on an unpatched ORM when the next PHP minor lands.
• Security response depends entirely on the fork's maintainers. There is no identifiable commercial support vendor in the package metadata — verify before any production commitment.
• Migration tooling and dialect coverage (MySQL/Postgres/SQLite) need direct verification rather than assumption from upstream docs, which are partially stale.

Key questions

• Which PHP and Laravel versions are in CI, and is there a published compatibility matrix?
• Is the repository public with full history, issue tracker, and contribution activity? Who are the maintainers and what is the bus factor?
• Can Perpl share a PDO connection and transaction boundary with Eloquent, or does it mandate its own connection?
• Is the XML schema → class generator deterministic and diffable in CI, and how does it interact with Laravel migrations?
• Is there a documented upgrade path from Propel2, and a documented exit path back to PDO/Doctrine?
• Any known CVEs in the Propel2 lineage carried forward, and what is the disclosure policy?
• Does it behave correctly under Laravel Octane / long-running workers, where static runtime config can leak across requests?

Integration Approach

Stack fit

• Recommend only for the two fit cases above. For a standard Laravel product, the correct comparison set is Eloquent (default) or Doctrine via laravel-doctrine (if a data-mapper is genuinely required) — both have first-class Laravel integration and hiring pools.
• If the driver is a legacy Propel2 system, Perpl is the lowest-friction continuity option and should be positioned as a bridge, with an explicit end state, not as a permanent architectural choice.

Migration path

• From Propel2: near drop-in — swap the package, regenerate classes, run the existing test suite, and diff generated SQL against a snapshot. This is the only path with a credible low-risk profile.
• From Eloquent: do not attempt. It is not a migration target; it is a rewrite of the persistence layer with a net loss of ecosystem support.
• If Perpl is mandated by a shared-schema constraint, isolate it behind repository interfaces so application code never imports generated classes directly. That boundary is what makes a later exit affordable.

Compatibility

• Pin the PHP minor explicitly and pin the Perpl version with a tight constraint; do not float.
• Verify PSR-4 autoloading of generated classes and explicitly configure static analysis (PHPStan/Psalm) to include or exclude the generated directory — otherwise you either analyze thousands of generated lines or silently lose type coverage.
• Confirm coexistence rules with Laravel's DB facade and connection config; document which layer owns connection settings to avoid two sources of truth.

Sequencing

1. Spike (1 sprint): branch-only install, generate from a copy of the real schema, run read-only queries, benchmark against the equivalent Eloquent path, and record PHP/Laravel compatibility results.
2. Boundary design: define repository interfaces for the one bounded context you intend to use; nothing else in the app may import Perpl.
3. Canary: land it on a single low-blast-radius context (reporting, import pipeline, or a read-heavy admin surface) — never on the core domain or anything in the payment/auth path.
4. Exit criteria and rollback: write down, before production code, what would cause you to abandon the dependency (missed PHP support, unpatched CVE, maintainer inactivity for N months) and how you would revert.

Operational Impact

Maintenance

• Generated model classes in version control create steady review noise and make every library upgrade a regeneration-and-diff exercise. Budget recurring time for this, not a one-off.
• The generator version is coupled to the library version; an upgrade is not a composer update — it is a regenerate, re-diff, re-test cycle.
• Expect to carry local patches. On a project this size, "we'll upstream it" is optimistic; assume you own the fix.

Support

• Community support is thin. Plan for source-reading as the primary support channel, with the Propel2 documentation as a partially stale secondary reference.
• No identifiable commercial support vendor — confirm this early; if the package is load-bearing, the absence is a material risk that should be accepted explicitly by an accountable owner, not absorbed silently by the team.

Scaling

• Propel's generated-query approach performs well for read-heavy, well-indexed access patterns; raw throughput is unlikely to be the constraint.
• The real scaling question is runtime model: Octane, Swoole, and queue workers all need validation because static runtime configuration and identity maps are classic sources of cross-request state leakage.
• Connection management is duplicated if you run both ORMs — size the pool for two consumers, not one, and measure before you assume it's free.

Failure modes

• Upgrade wall: the fork lags a PHP or Laravel release and blocks your own upgrade, converting a convenience dependency into a platform ceiling.
• Transaction split: partial commits across Eloquent and Perpl on shared business operations — silent data corruption, discovered late.
• Schema drift: Laravel migrations and the Perpl XML schema diverge, producing environments that disagree about the schema.
• Abandonment: maintainer goes inactive mid-project with no drop-in replacement ready; the repository-interface boundary is what determines whether this is an inconvenience or an incident.
• Security latency: a CVE in the lineage with no patch path and no vendor to escalate to.

Ramp-up

• Steep for an Eloquent-fluent team: XML schema DSL, generated base classes, a different query/criteria API, and different hydration and lazy-loading semantics. Realistic estimate is 2–3 weeks to working competence for a mid-level engineer, longer for the schema-generation workflow.
• The durable cost is not the initial ramp — it is the permanent context tax of a second ORM in the codebase: every new engineer learns two persistence idioms, and every architectural decision must account for both.
• Recommended stance: approve for legacy-continuity scenarios with an explicit exit plan and an accountable owner; decline for greenfield Laravel work, where the opportunity score of 2.23 and 26-star footprint accurately reflect that Eloquent or Doctrine is the better-supported answer to the same problem.