Laravel Eloquent Metable Laravel Package

Product Decisions This Supports

• Build vs. buy for model metadata: A metable package answers the recurring "where do we store per-record attributes we didn't model upfront?" question — CMS settings, feature flags per entity, marketing copy, integration IDs, audit annotations. This package lets you ship that capability in hours rather than designing a polymorphic meta table, accessors, casting, and query scopes in-house.
• Roadmap sequencing for admin/config features: Teams routinely defer "let admins edit extra fields without a migration" to a later quarter. A metable layer moves that work off the migration-dependent critical path, letting schema-stable features ship first.
• Schema-change avoidance as a cost lever: Every ad-hoc column added for a one-off client or experiment carries migration, backfill, and rollback cost. Meta storage trades schema churn for JSON payloads — useful for MVPs, pilots, and single-tenant customizations, and a defensible reason to defer a normalized schema.
• v1.0.0 API stability signal: The 1.0 tag — with a first contributor and an explicit ULID addition — is the point at which "is this going to churn under us?" becomes answerable. A stable major version supports adopting it in production rather than a spike.
• ULID support widens fit: ULID keys (sortable, URL-safe, non-enumerable) matter where meta records leak into exports, APIs, or public identifiers. Pre-1.0 that would have been a fork or a PR; now it is a supported option, which unblocks adoption in products with externally visible IDs.
• Not a decision driver: The release notes are thin ("updates | enhancements"). Treat v1.0.0 as a packaging milestone, not a capability expansion — scope the evaluation to what metable storage does generically, not to the changelog.

When to Consider This Package

Adopt when:

• You need arbitrary key/value attributes on Eloquent models with a small, stable set of access patterns (read, write, cast, occasionally filter).
• Your team is Laravel-native and wants a conventional package rather than a bespoke polymorphic table.
• You expect schema volatility — experiments, per-customer fields, or content that non-engineers edit.
• ULID identifiers are on your requirements list for anything externally exposed.
• You can tolerate vendor-maintenance risk: a single author with a first-time contributor is thin coverage for a data-layer dependency.

Look elsewhere or build in-house when:

• You need to query, sort, or aggregate on meta values at scale. JSON/EAV storage degrades under reporting load; a normalized schema or a dedicated store is the right call.
• Referential integrity, foreign keys, or strict typing on the metadata are requirements — meta tables are deliberately schemaless.
• You need compliance-grade audit trails (who changed which field when, immutable history). Metable gives you current state, not lineage.
• The metadata is actually first-class domain data. If a field is core to the product, model it as a column; meta is for the long tail.
• Ecosystem maturity is a hard gate. Compare against better-established alternatives (e.g. Spatie's schemaless attributes, plank/laravel-metable) before committing; the feature gap may be smaller than the maintenance-risk gap.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a small, free Laravel package that lets us attach flexible extra fields to records without database migrations. It buys speed on config-heavy and per-customer features and reduces schema churn, at the cost of one more third-party dependency maintained by a single author. The 1.0 release is the signal that it is stable enough to evaluate in production. Recommendation: pilot on one non-critical feature, no broad rollout yet.

For engineering: Generic metable behavior for Eloquent models — polymorphic metadata with casts, plus ULID support as of v1.0.0. The 1.0 tag is new and the changelog is not detailed enough to assess regression risk; review the source and test coverage directly before adoption. Known trade-off: meta lives in JSON, so querying and aggregation on meta values will not scale — use it for the long tail of attributes, not for fields you will report on. Please return an opinion on build-vs-adopt against our existing schemaless-attributes usage and flag any query patterns in our codebase that would fight this design.

Decision requested: Approve a timeboxed spike (1–2 days) on a low-risk feature; no production commitment until the maintenance-risk review lands.