Perpl Laravel Package

Product Decisions This Supports

• Legacy data-layer continuity vs. rewrite. The core decision this enables is whether to keep an existing Propel/Propel2-backed application on life support or fund a migration to Eloquent/Doctrine. Perpl gives you a third option — a maintained fork — which converts a "rewrite the persistence layer" line item into a much cheaper "upgrade dependency + patch" line item.
• Build vs. buy on ORM maintenance. If your team has already forked Propel internally, Perpl is a candidate to retire that internal fork and move the maintenance burden to an upstream. This is a classic "stop paying engineers to be a maintainer" decision, priced at MIT.
• Schema-first vs. code-first domain modeling. Propel's model is schema (XML/YAML) → generated classes → Active Record + explicit query API. Adopting Perpl is a decision to keep generated, IDE-navigable model code rather than annotation/attribute-driven mapping (Doctrine) or Eloquent's fluent magic. This affects onboarding, static analysis coverage, and how much of your domain is expressible in code review.
• Performance/roadmap trade-offs. Propel's pitch is lean runtime overhead and predictable SQL for read-heavy, join-heavy workloads. Perpl keeps that profile; it supports decisions like "do we keep raw/query-builder paths for hot endpoints" and "do we accept a smaller ecosystem to avoid Doctrine's hydration overhead."
• Vendor and platform risk register entries. 26 stars and a small maintainer base is itself a product risk input. The decision this supports is how much of your critical path you're willing to put behind a low-traction dependency, and what the exit plan costs.
• Modernization sequencing. Because Perpl is a fork with ongoing releases, it unblocks PHP-version and database-driver upgrades now — letting you sequence "get to supported PHP" before "replace the ORM," rather than doing both in one risky release.
• Laravel-specific scope decision. Perpl is an ORM, not a Laravel integration. Adopting it forces a conscious decision about how far you go: coexist alongside Eloquent (two persistence stacks, two migration stories), or keep it confined to a bounded context/service layer. The latter is usually the only defensible scope.

When to Consider This Package

Consider it when:

• You have an existing Propel or Propel2 codebase that is falling behind supported PHP/runtime versions, and the schema-first, generated-model workflow is deeply embedded in your code and team habits.
• Your workload is read-heavy and join-heavy, with SQL you want to reason about explicitly rather than through a data-mapper abstraction.
• Your domain is large and stable, so code generation and deterministic model classes reduce review and onboarding cost.
• The blast radius is containable — a service, an internal tool, or a bounded context — and you can own the fork if upstream stalls.
• You're willing to do integration work: service provider wiring, transaction handling with Laravel's queue/HTTP lifecycle, and bridging auth/session if those currently assume Eloquent.
• You can accept MIT with no commercial support, no SLA, and a small contributor base.

Look elsewhere when:

• You're greenfield in Laravel. Use Eloquent. The framework's auth, policies, factories, seeders, broadcasting, and the majority of third-party packages assume it; fighting that is a permanent tax with no compensating benefit.
• You need a hiring pipeline. Doctrine and Eloquent are searchable skills; Propel-adjacent experience is rare, and a 26-star fork is not a resume line.
• You need managed migrations, multi-tenancy, soft deletes, or an auditing ecosystem out of the box — these are Eloquent/Doctrine strengths and Propel weak spots.
• You require vendor indemnity, security SLAs, or long-term support contracts.
• Your team is small, has no ORM-internals depth, and would be unable to patch upstream. With this dependency, "we can fix it ourselves" is a load-bearing assumption, not a nice-to-have.
• The migration cost to Eloquent/Doctrine is genuinely comparable to the integration + risk cost of Perpl. Run that comparison explicitly — the fork's low adoption often makes the "cheap option" more expensive than it looks.

Due diligence before committing: commit cadence over the last 12 months, test suite coverage and CI matrix (PHP versions, MySQL/Postgres/SQLite), issue/PR responsiveness, release notes for breaking changes across fork versions, database driver parity, and the concrete diff versus upstream Propel2 so you know what you're inheriting.

How to Pitch It (Stakeholders)

To executives: This is a risk-and-cost decision, not a technology preference. We have a persistence layer that is drifting off supported PHP; the two alternatives are a multi-quarter rewrite or a low-cost dependency upgrade. Perpl is an actively released, MIT-licensed maintained fork of the ORM we already run. It buys us time and keeps our upgrade path open at near-zero license cost. The trade-off is real and should be stated plainly: it has a small community (roughly two dozen GitHub stars), no commercial support, and effectively no hiring pool — so we treat it as a tactical bridge, budget a defined exit plan, and cap its blast radius to the services that already depend on this ORM.

To engineering: Perpl preserves the schema-first, generated-model workflow you already know — schema files in, model classes out, explicit query API, predictable SQL. It brings the fork current with supported PHP and database drivers, so upgrading PHP stops being blocked on the ORM. What we are not doing is standardizing on it: it is not a Laravel citizen, there is no first-party service provider or migration integration, and it does not interoperate with Eloquent-based packages. So we scope it to existing Propel-backed contexts, isolate it behind repository interfaces, and do not introduce it into new code. We also assume we may have to carry patches ourselves — anyone proposing adoption should be able to say who owns that.

The one-line version: a cheap, credible way to stop a legacy ORM from blocking platform upgrades — worth adopting where Propel already lives, wrong everywhere else.