Suitable Laravel Package

Product Decisions This Supports

• Custom-field / flexible-attribute filtering. Support for the -> operator when searching a JSON column means a single JSON column (e.g. metadata, settings, attributes, payload) can be queried by key — where('metadata->plan', 'pro') — instead of requiring a schema migration for every new filterable attribute. This directly enables roadmapped features like user-defined fields, per-tenant configurable filters, and admin-side advanced search.
• Build vs. buy. Path-aware JSON querying is deceptively fiddly (path escaping, key quoting, nested depth, driver differences, whereJsonContains vs. like semantics). This release extends the package's existing search/filter surface rather than forcing the team to hand-roll a query-builder abstraction, so the recommendation stays buy/adopt for the filtering layer.
• Roadmap unlock, low cost. 3.6.12 is a patch-level release: additive capability, no breaking changes, no deprecations. It can be scheduled as routine dependency maintenance rather than a migration project, which means the dependent feature (e.g. "filter records by custom metadata") can be scoped into the current or next cycle.
• Use cases this supports: CMS/CRM record search across arbitrary attributes; e-commerce product attribute filtering; SaaS admin consoles where tenants define their own filterable fields; log/event inspection where context lives in a JSON blob; saved-search and alerting features that persist a filter definition referencing JSON paths.
• Scope discipline. It makes JSON columns queryable in the same filter UI as first-class columns. That keeps one filtering code path and one mental model for the team, rather than a bolted-on "JSON search" sidebar.

When to Consider This Package

Consider adopting when:

• Your schema already uses (or is about to use) JSON columns for variable attributes and product needs user-facing filtering on those keys.
• You are on a supported Laravel version and a driver with JSON support (MySQL 5.7+/8, PostgreSQL json/jsonb, SQLite with the JSON1 extension). Confirm your matrix explicitly — JSON path behavior is the most likely thing to differ.
• Filtering is exact-ish or prefix in nature (=, like, in), which is what JSON path predicates are good at.
• You want filtering logic expressed declaratively in the app layer, testable, without raw SQL strings in controllers.
• You are already a consumer: this is a reason to stay current on patch releases, not a reason to re-evaluate.

Look elsewhere (or extend) when:

• You need relevance/ranked full-text search — reach for Laravel Scout with Meilisearch/Typesense/Algolia/Elasticsearch instead. JSON path predicates are filters, not a search engine.
• You need aggregations, facets, or analytics over JSON fields at volume — use generated/computed columns, purpose-built indexes, or a columnar/OLAP path.
• Query performance is already tight. A -> path predicate on a plain JSON column generally cannot use a standard index. Plan for generated columns + indexes (MySQL/Postgres) or a denormalized read model before shipping this behind a high-traffic endpoint.
• You need cross-database portability guarantees or support legacy drivers without JSON path support.
• You need very complex boolean/nested group logic that exceeds the package's filter DSL — raw query builder or a dedicated search service is clearer.

Adoption criteria / checklist: verify the Laravel + DB driver versions in your matrix; add integration tests covering nested paths and reserved/special characters in keys; measure the generated SQL on a realistic table size; confirm no reliance on the exact path-parsing behavior of the previous minor.

How to Pitch It (Stakeholders)

For executives (one paragraph): A routine, non-breaking patch release of a package we rely on for filtering and search. It adds the ability to filter records on fields stored inside flexible JSON data — the practical effect is that we can ship custom-field and advanced-filter features without new database migrations or new search infrastructure, and therefore without new vendor spend or a platform project. Risk is low (patch version, no deprecations, no required code changes) and the payoff is a roadmap item becoming deliverable in an upcoming cycle rather than a dedicated initiative.

For engineering leads: Semver-patch, additive only — support for the -> operator when searching JSON columns. No API removals, no config changes, no deprecations; upgrade is a composer bump plus a test run. Two caveats worth ticketing: (1) JSON path predicates typically don't use indexes — benchmark on production-shaped data and prefer generated columns for hot filters; (2) add coverage for nested paths and keys containing special characters, since path parsing is the fragile seam. Please also confirm our supported driver matrix in CI exercises at least one JSON-path-capable and one non-capable configuration if we claim portability.

For the product team: Net effect is that "filter by any custom field" moves from needs backend schema work to configurable in the existing filter UI. No user-visible change on its own; it's the enabler for the custom-fields and saved-search stories.