Orm Laravel Package

Product Decisions This Supports

• Build vs. buy for the persistence layer (re-scored). mindy/orm is no longer just a data mapper: 4.0.4 adds JSON field support and a QueryBuilder. That moves it from "CRUD mapping only" to "CRUD plus ad-hoc querying," which makes it a more credible comparison point against a hand-rolled repository/query layer for non-Laravel PHP services and standalone scripts. The build-vs-buy estimate should now account for the fact that query construction and JSON serialization are partly covered.
• Scoping early-stage/internal tools. JSON column support matters for the shape of modern small apps (settings blobs, semi-structured payloads, event metadata). This widens the set of internal tools where the package could be a "minimum viable persistence" choice rather than requiring custom encode/decode code around a simpler mapper.
• Schema and data-model decisions for small services. If a service's roadmap leans on JSON columns (feature flags, flexible attributes, audit payloads), the presence of native JSON field handling is a concrete input to "do we model this relationally or as JSON?" — a decision that is expensive to reverse later.
• Roadmap triage on standardization. Within the Eloquent vs. Doctrine/Cycle vs. micro-ORM spectrum, this package now sits closer to "viable micro-ORM" than "toy mapper." It bounds the low end of the trade-off discussion more honestly than before, but it still does not change the recommendation for Laravel-based work.
• Dependency governance scorecard — updated inputs. Two signals changed: (1) release activity has resumed on a 4.x line, so the earlier "no releases since February 2018" characterization is stale; (2) a QueryBuilder and JSON support shipped in a patch release (4.0.4), which is a semver-hygiene flag — consumers on ^4.0 inherit new API surface without a minor bump. Both belong in the objective adoption criteria we apply to every dependency.
• Not a decision driver for Laravel work. Eloquent remains the default and a second ORM adds cognitive load and integration risk. This has not changed.

When to Consider This Package

Consider it only when all of the following hold:

• The service is plain PHP or MindyPHP-based, not Laravel, and you explicitly do not want a full framework or Eloquent.
• Requirements are simple CRUD mapping plus straightforward querying — the new QueryBuilder covers your read paths, and JSON field support covers your semi-structured columns. Verify coverage against your actual query shapes; the builder is new and its feature surface is undocumented in the release note.
• The team is comfortable owning the code — forking or vendoring it. Release activity has resumed on the 4.x line, but adoption is still effectively zero, so there is no community safety net and no guarantee of continuity.
• You pin to an exact version rather than a floating constraint, given that feature-level additions are landing in patch releases.
• There is a documented exit plan to a maintained ORM (Doctrine, Cycle, Eloquent via a bridge) if requirements grow.
• It has passed a security and compatibility review against your target PHP version and dependency policy — with specific attention to the new QueryBuilder's parameter binding and escaping, since it is new code in a data-access path.

Look elsewhere when:

• You are building on Laravel — use Eloquent; a second ORM adds cognitive load and integration risk for no benefit.
• You need active maintenance, security patches, or community support — resumed releases are a positive signal but not a substitute for a maintainer base; 0 dependents and a very small star count still mean no upstream safety net.
• The domain needs complex querying, performance tuning, or large-team conventions — Doctrine or Cycle remain better fits, and a newly introduced builder is unlikely to match their maturity.
• Your organization has a dependency governance policy requiring recent releases, minimum adoption signals, a maintained maintainer, or strict semver discipline.
• You cannot accept the fork-and-own cost or the risk of an unmaintained dependency in production.

How to Pitch It (Stakeholders)

To executives: The picture has improved at the margins but the conclusion holds. The project has resumed releasing on a 4.x line and 4.0.4 adds JSON field support and a query builder, so it is more capable than the version we last assessed. Adoption, however, is essentially unchanged (single-digit stars, no dependents), and the maintainer base is still too thin to treat as a strategic dependency. Continued risk is that a data-access layer is silently abandoned — expensive to unwind once it has leaked into domain code. Recommendation: do not adopt for new customer-facing or long-lived work; keep it as a reference point in the build-vs-buy estimate for persistence, and price any micro-ORM choice against maintained alternatives or a budgeted fork. One process note worth flagging to engineering leadership: a query builder shipped in a patch release, which is a release-discipline observation for our dependency scorecard.

To engineering: The package is still small and readable, but it is no longer "data mapper only." 4.0.4 adds JSON field support and a QueryBuilder, which materially narrows the gap versus a hand-rolled persistence layer for simple services. Two practical consequences. First, pin exact versions — new API surface is arriving in patch releases, so ^4.0 is not a safe constraint if you need stability. Second, review the QueryBuilder before trusting it: it is new code on a data-access path, so check parameter binding, identifier quoting, and how it composes with the JSON field handling on your target PHP version and database driver. If you do adopt, keep it for throwaway or internal tooling, hide it behind a thin repository interface so it never leaks into domain code, and carry a written migration path. For anything customer-facing or long-lived, standardize on Eloquent (Laravel) or Doctrine/Cycle.