mindy/orm
Mindy ORM is a Laravel/PHP ORM package for modeling database data and relationships in PHP applications. It offers an alternative ORM layer for common model and query workflows, but has minimal adoption and limited community feedback.
Architecture fit. Unchanged by 4.0.4. mindy/orm remains a component of the Mindy PHP micro-framework, not a Laravel package: no service provider, no facade, no publishable config, no illuminate/* integration points. The release adds JSON field support and a QueryBuilder, which makes the component more self-contained and therefore less likely to interoperate with Eloquent — it now ships its own query-construction surface in addition to its own mapping layer. Adopting it still means running a second persistence abstraction beside Eloquent, with two competing models of connections, transactions, hydration, and events. The JSON-field work is a parity feature, not a differentiator: Laravel already handles JSON columns natively via $casts, whereJsonContains, and whereJsonLength. Nothing here creates a capability gap that Eloquent cannot close.
Integration feasibility. Marginally better in the sense that the package is demonstrably buildable and taggable in its current form; unchanged in every way that matters for us. There is still no adapter, no container binding, no documented Laravel lifecycle story, and no compatibility matrix. The 4.0.4 notes introduce a second coupling to reason about: an explicit QueryBuilder >= 4.0.4 relationship. That is an internal-version pin on a sibling Mindy component, which means adopting this ORM pulls a transitive version constraint on another unmaintained package with no independent release cadence we can plan around. Expect the adapter shim to be at least as large as previously estimated, plus a new pin to audit.
Technical risk. Still the dominant concern, with one fact corrected and one question opened. Corrected: the earlier claim of "no release since February 2018" is now stale — 4.0.4 exists and was published recently. That is a genuine positive signal and should be recorded as such. It is also a single data point, and a two-line changelog in Russian with no CI badge, no test-coverage claim, no PHP-version matrix, and no stated support window. A release after a multi-year gap is characteristic of a solo maintainer shipping a fix for their own downstream need, not of a project that has re-established a maintenance process. The 4-star / 0-dependent adoption picture, and therefore the composite of 0.11, is unchanged. Version numbering at 4.0.4 implies a prior 4.x line, which raises the question of whether earlier 4.x releases were yanked, retagged, or never announced — worth resolving before pinning anything.
Key questions. Updated set:
QueryBuilder >= 4.0.4 dependency satisfied by a separately published package, and does that package have its own maintenance signals?->>/JSON_EXTRACT, PostgreSQL ->/#>> and jsonb, SQLite json_extract all differ. If this was built against one engine, parity elsewhere is unproven and the feature is a portability trap.Stack fit. Poor, for the same reasons. Laravel's persistence story is Eloquent plus Illuminate\Database, with migrations, factories, model events, broadcasting, and Octane-safe connection handling. 4.0.4 does not move this package toward that stack; if anything, shipping its own QueryBuilder widens the feature overlap and increases the chance of two different query-construction idioms in one codebase. The only plausible fit remains a non-Laravel PHP service deliberately avoiding a framework — and even there, Doctrine DBAL, Cycle ORM, or plain PDO remain better-supported.
Migration path. Unchanged. Repository-interface strangler only: hide Mindy behind UserRepository/OrderRepository, run alongside Eloquent against the same database, one ORM per transaction boundary, no write-path overlap. The new JSON support slightly expands what a pilot could cover — a read-only query path over a table with a JSON column is now a defensible spike scope, and is a better test than a plain scalar read because it exercises the feature that motivated the release.
Compatibility. Same matrix to verify — PHP, Laravel, DB engine and version, PHPUnit — with one addition: resolve the QueryBuilder >= 4.0.4 constraint against our lockfile first, because a conflicting transitive pin discovered late invalidates the whole spike. Also confirm that 4.0.4 does not relax a PHP constraint in a way that only works on the maintainer's machine. Any outcome that requires pinning the application to an older runtime remains disqualifying.
Sequencing. Unchanged, with the spike scope adjusted: (1) one developer, one week, proving PHP 8.x + our DB engine + a read-only query path including a JSON column read and a JSON predicate; (2) confirm the QueryBuilder dependency resolves and is itself maintained; (3) architectural review against the repository-interface boundary; (4) fork decision and ownership assignment, now covering two components; (5) pilot in a single low-risk, read-heavy context; (6) go/no-go against an explicit exit criterion. A release note is not evidence that displaces "use Eloquent properly" — it must still lose that comparison on merit.
Maintenance. Still effectively total, with a marginally better opening position. The 4.0.4 release proves the upstream is not dead, which removes the worst-case "we are the only human who has read this code in six years" framing. It does not prove a cadence. One release does not let us plan quarterly dependency bumps, and there is no published policy for PHP minor-version support or security triage. Budget the same recurring fork-and-own cost, and add a second line item for the QueryBuilder component the release introduces.
Support. Unchanged: no vendor, no community, no Stack Overflow corpus, no issue-tracker throughput to cite. A recent tag slightly improves the odds that a filed issue gets read; it does not constitute support. Persistence-layer incidents are where data corruption happens, and the supportability question is still decisive.
Scaling. Unchanged and still unvalidated. No benchmarks, no pooling story, no Octane/Swoole evidence. The JSON feature adds a scaling-adjacent unknown: JSON predicate performance is highly engine-dependent (functional indexes, generated columns, jsonb GIN indexes), and there is no indication the release accounts for any of that. Observability remains weaker than Laravel Telescope/Debugbar.
Failure modes. The prior set stands — hydration divergence between the two ORMs, transaction leakage on interleave, PHP-version deprecations surfacing as fatals after a routine upgrade, abandoned-dependency scanners flagging the package and blocking CI, loss of Laravel-native model events/casts/soft deletes/eager loading. Two additions from 4.0.4: (f) JSON dialect drift — predicates that behave correctly on the maintainer's engine and silently differ (or throw) on ours, which is a correctness bug surfacing in production rather than in CI; (g) transitive version pin on QueryBuilder >= 4.0.4 becoming unsatisfiable alongside our other constraints, forcing a fork of a second repository we did not choose to own.
Ramp-up. Unchanged in shape: cheap to read, expensive to own. The release notes are two lines, in Russian, with no usage examples, no migration notes for the JSON feature, and no documentation update — which is the same documentation deficit as before, now confirmed as current behaviour rather than historical neglect. API knowledge stays tribal. New engineers would still be learning a persistence layer with no market value and no external references.
Recommendation. Do not adopt. The 4.0.4 release is a real but small positive signal: the project is not abandoned, and JSON field support plus a QueryBuilder narrow two genuine gaps. Neither gap is a gap for us — Eloquent covers JSON columns and query construction natively and better — and a single release does not offset 4 stars, 0 dependents, no tests or CI evidence, no compatibility matrix, and no support channel. The composite of 0.11 and opportunity score of 13.93 should be treated as substantially unchanged pending a scored re-evaluation; one tag is not a trend. If a specific Eloquent limitation is driving this evaluation, characterize it precisely and evaluate maintained alternatives (Doctrine DBAL, Cycle ORM) or contribute upstream to Laravel. Revisit only if the project demonstrates a sustained release cadence over at least two subsequent quarters and publishes a PHP 8.x test matrix — at which point the spike in the sequencing section becomes worth funding.
How can I help you explore Laravel packages today?