Search Doctrine Dbal Laravel Package

Product Decisions This Supports

• Advanced search/filtering feature scoping. The package provides a structured way to translate user search criteria into Doctrine DBAL queries (field matchers, comparisons, value matching). It informs whether a filtering/search capability should be built on a reusable query-builder layer or hard-coded per screen.
• Build vs. buy for search internals. For teams with a Doctrine DBAL data layer, it is a candidate to buy rather than build the "criteria → SQL" translation layer, freeing roadmap capacity for UI and relevance tuning.
• Roadmap risk and sequencing. v2.0.0 is alpha with a documented BC break; this supports a decision to keep any dependent feature behind a flag or out of committed release dates until a stable 2.x lands.
• Capability trade-off decisions. Removal of the Regex ValueMatch is a feature regression for pattern-based search. Any planned "regex/pattern search" requirement must be re-scoped (e.g., moved to LIKE/prefix matching, application-side validation, or a dedicated search engine) before it enters a roadmap.
• Architecture/ecosystem fit. The package is framework-agnostic (Doctrine DBAL), not Laravel/Eloquent-native — this informs whether a Laravel-centric product should consider it at all versus staying within Eloquent/Scout.

When to Consider This Package

Consider it when:

• Your application persists data through Doctrine DBAL (not pure Eloquent), and you need a reusable, composable way to express search criteria as SQL.
• You want consistent, auditable query generation for admin panels, reporting, or internal tooling with many filter combinations.
• You can tolerate pre-release (alpha) APIs and have the appetite to pin versions and absorb breaking changes.
• Your search requirements are comparison/equality/set-based rather than free-text relevance ranking.

Look elsewhere when:

• You are a standard Laravel/Eloquent stack — Laravel Scout, database full-text indexes, or Meilisearch/Typesense/Elasticsearch will be a better fit and far lower integration cost.
• You require regex or arbitrary pattern matching in search criteria — that capability was deliberately removed in this release and will not be restored by this package.
• You need production-stable, semantically-versioned guarantees — alpha status and BC breaks make this unsuitable for committed delivery timelines.
• Your core need is relevance ranking, faceting, or typo tolerance — this is a query-composition layer, not a search engine.

How to Pitch It (Stakeholders)

To executives: This is a small, open-source PHP component that helps generate database search queries. It is currently in alpha and just shipped a breaking change that removes a pattern-matching capability. Recommendation: do not commit it to customer-facing roadmap dates; treat it as an internal evaluation. If we pursue it, it saves engineering effort on search plumbing — but only if our stack uses the relevant database layer.

To engineering: The library targets Doctrine DBAL, not Eloquent, so for most of our Laravel services the integration cost likely outweighs the benefit; Scout or a dedicated search service remains the default. Where we do have a DBAL data layer, it offers a clean criteria-to-SQL abstraction. Note the v2.0.0-ALPHA3 BC break: Regex ValueMatch support is removed — any code or test relying on regex matching must migrate to alternative matchers or implement matching upstream. Pin the exact alpha version, isolate usage behind an interface, and plan for further churn before 2.0 stable.

Bottom line: Evaluate, don't adopt broadly yet. Revisit at a stable 2.0 GA or when a concrete DBAL-based search requirement appears.