Laravel Dynamic Model Laravel Package

Product Decisions This Supports

• Custom-field / extensible-schema features: laravel-dynamic-model lets you define Eloquent models, tables, and columns at runtime instead of at build time. This is the enabling primitive for user-defined fields, admin-configurable form builders, per-tenant schema customization, and "no-code" data capture — features that otherwise require a hand-rolled EAV layer or a metadata service.
• Build vs. buy: If the roadmap contains a "let customers define their own record types" item, this package collapses weeks of internal schema-manipulation and model-generation work into a dependency. The trade-off to price in is that runtime DDL is an operational liability (see below), not just a code dependency.
• Roadmap sequencing: Adoption makes most sense as a foundation for a single well-scoped feature (e.g., custom fields on a core entity), not as a general-purpose ORM replacement. PM should scope it to one surface area first and measure query complexity and migration drift before expanding.
• Deployment risk for this release: v4.0.0 is a major version whose only substantive change is Laravel 13 support plus CI/dependency bumps. In practice this means the Laravel version constraint moved forward — likely dropping older Laravel support — even though no API-level breaking changes are spelled out in the notes. If the product is on Laravel 11/12, this release is a no-op for you and the v3 line remains correct; if Laravel 13 is on the upgrade roadmap, v4 is the unblocker.
• Upgrade planning: Because the changelog is thin, treat v4 as "verify, don't assume." Budget a spike to confirm actual constraint changes and run the existing dynamic-model test suite before scheduling the Laravel 13 upgrade as a committed deliverable.

When to Consider This Package

Adopt when:

• The product genuinely requires runtime-defined schema (tenant-custom fields, user-authored collections, plugin-style extensions). If the schema is known at build time, use normal migrations — this package is the wrong tool.
• The dynamic data needs to be queried through Eloquent — relationships, scopes, accessors — and a JSON-column approach would make querying and indexing painful.
• The team is on, or moving to, Laravel 13 and wants a maintained path for the capability.
• The dynamic surface area is bounded: a handful of tables and moderate row counts, not the system of record for high-volume analytics.

Look elsewhere when:

• Analytics/BI is the destination. Runtime-created tables are hostile to reporting, warehouse sync, and schema-aware tooling; prefer JSON columns (Postgres/MySQL 8) or a dedicated store.
• Compliance, audit, or data-residency requires stable, reviewable schema changes with migration history. Runtime DDL bypasses normal review and rollback.
• Multi-tenant scale with per-tenant DDL is expected — hundreds of generated tables create migration/backup/permission sprawl; a shared-table EAV or JSON design usually wins.
• The team is on Laravel 11/12 and not planning to move — stay on v3.0.4; v4 buys you nothing and adds upgrade churn.
• You need a large, actively maintained ecosystem — this is a small, single-maintainer package. Absorbing it means owning the failure mode internally.

How to Pitch It (Stakeholders)

For executives: This is a small open-source Laravel package that lets the application create database structures and models at runtime, which is what makes "custom fields" and customer-defined record types possible without a major custom build. The new v4.0.0 release is a compatibility release — it adds Laravel 13 support; there are no new user-facing features. Cost is low, but so is the margin for error: it shifts schema control to end users, so we should adopt it for one contained feature and keep it away from reporting and compliance-sensitive data.

For engineering: v4.0.0 is effectively a Laravel 13 support bump plus Dependabot housekeeping (ramsey/composer-install 3→4, dependabot/fetch-metadata 2.5→3). The major version signals a changed Laravel constraint rather than documented API breaks — verify constraints and run the suite before upgrading. Recommendation: pin to v3.0.4 while on Laravel ≤12; plan v4 as part of the Laravel 13 upgrade workstream. Note the package is single-maintainer and does runtime DDL — keep generated tables out of the analytics path, and wrap adoption in a feature flag so it can be withdrawn without a data migration.