Search Bundle Laravel Package

Technical Evaluation

Architecture fit. The headline framing needs correcting before any decision: whatwedo/search-bundle is a Symfony bundle built on Doctrine ORM, not a Laravel package. It delivers full-text search by pushing matching down to the relational database (native MATCH … AGAINST / tsvector style capabilities plus a maintained index table) rather than adding a sidecar service. For a Symfony + Doctrine codebase this is a strong architectural fit — no new infrastructure, no data duplication into a third-party cluster, no operational surface beyond the database you already run. For a Laravel/Eloquent codebase it is effectively a non-starter without a Doctrine bridge, which itself is an architectural change far larger than the search feature.

Integration feasibility. The surface area is small and idiomatic: annotate/attribute entities as searchable, let Doctrine lifecycle listeners keep an index table current, and expose a query API plus console commands for (re)indexing. That is a well-understood shape for a Symfony team and should be a days-not-weeks integration for a single bounded context. Feasibility is gated almost entirely on how cleanly the target entities map to a single searchable projection.

Technical risk.

• Adoption signal is the dominant risk. 11 stars, zero dependents, and a composite score near 1.0 mean essentially no production validation in the wild. Treat this as "unproven library" rather than "mature component."
• Bus-factor and maintenance continuity. A single-maintainer, low-traffic bundle is a fork-or-replace liability on any multi-year roadmap.
• Database coupling. Correctness and relevance depend on the underlying engine's tokenizer, stemming, and stop-word behaviour; results and performance will differ between MySQL and PostgreSQL and across versions. Behaviour is not portable, and relevance tuning is largely hand-rolled SQL.
• Index consistency. Listener-based sync covers ORM writes but silently misses bulk DQL UPDATE/DELETE, raw SQL, fixture loads, and out-of-band migrations — the classic stale-index trap.
• Relevance and ranking depth. Expect basic term matching; no faceting, fuzzy matching, synonyms, or learned ranking without custom work. Acceptable for admin/internal search, risky for customer-facing discovery.

Key questions.

1. Which Symfony, PHP, Doctrine ORM, and DB platform/version combinations are actually supported and CI-tested?
2. What is the release cadence and issue-response history over the last 24 months? Any tagged release in the last year?
3. Which database engines are supported, and is the generated SQL dialect-aware or string-concatenated?
4. How is the index kept in sync for bulk operations, and what is the documented recovery path (full reindex command, downtime characteristics)?
5. Does the query API support pagination, ordering, multi-field weighting, and scoping/filtering by tenant or ACL?
6. Is there meaningful test coverage, and is the licence/contribution posture compatible with us maintaining an internal fork?
7. Non-English content: what tokenization/stemming exists for our target locales?

Integration Approach

Stack fit. Go/no-go hinges on the framework: Symfony + Doctrine → viable, low-friction. Laravel/Eloquent or a mixed stack → do not proceed; evaluate Laravel Scout with a database driver, TNTSearch, or a managed search service instead. If the estate is polyglot, scope this to the Symfony services only and accept a second, divergent search pattern.

Migration path. Prefer an additive, strangler-style adoption: introduce the bundle behind a thin SearchService interface owned by our domain, with the bundle as the first implementation. Existing LIKE-based or manual query code stays in place until the new path is benchmarked against it. This makes the eventual swap to Meilisearch/OpenSearch/Elastic a contained change rather than a refactor, and directly neutralises the continuity risk.

Compatibility. Verify three axes before committing: framework/PHP version alignment with our support window; Doctrine ORM 2.x vs 3.x (attributes vs annotations, event API changes); and database platform parity across dev, CI, and production — including collation and full-text configuration drift. Also confirm the index table DDL ships as a Doctrine migration we can own, since our schema pipeline must be the source of truth.

Sequencing.

1. Spike (2–3 days): stand up one representative entity in a scratch environment, run the index command, measure query latency and result quality on a realistic corpus.
2. Risk gate: confirm maintainer responsiveness and that we can patch/fork; if either fails, stop and pick an alternative.
3. Index design: define the searchable projection, backfill/reindex job, and a scheduled reconciliation for drift.
4. Domain wrapper: implement SearchService with the bundle behind it, plus a feature flag.
5. Shadow run: dual-run against the incumbent search, compare result sets on real queries.
6. Cutover: flip the flag, keep the old path for one release, retire it.

Operational Impact

Maintenance. Low code churn means low ongoing effort, but also low upstream responsiveness. Budget for periodic upstream triage and assume we may need to patch. Plan the fork posture now: vendor the package, or maintain a maintained-fork branch with our own CI. Because the package's correctness depends on DB behaviour, our test suite must cover search semantics per supported engine, not just unit-level logic.

Support. No commercial backing, no SLA, community-only help. That is acceptable for internal/admin tooling and unacceptable for a revenue-path feature unless the wrapper abstraction is in place and a swap is pre-designed. Document the escape hatch (target engine, data export path, expected effort) before launch.

Scaling. The database does the work: index size and write amplification scale with the number of searchable entities and the frequency of writes, since each persisted entity touches the index. Read scaling is bounded by the primary's capacity or read replicas — replica-based search raises freshness questions (replication lag versus index lag). Reindex jobs on large tables are the practical ceiling: they are I/O-heavy, may hold locks, and should run batched, off-peak, and resumable. If search QPS ever rivals transactional QPS, this design should be replaced rather than tuned.

Failure modes.

• Silent staleness from bulk writes or raw SQL bypassing lifecycle events → mitigated by scheduled reconciliation and index-age monitoring.
• Relevance regressions after DB upgrades or collation/stop-word changes → mitigated by golden-query regression tests in CI.
• Reindex-induced degradation (lock contention, replica lag, memory) → batched jobs, chunked commits, off-peak windows.
• Dialect/version breakage on platform migration → pinned platform versions and a pre-migration search smoke test.
• Upstream abandonment → fork readiness and the abstraction layer.
• Result-set exposure — search must respect tenant and permission scoping explicitly; do not assume the bundle enforces ACLs.

Ramp-up. The learning curve is shallow for developers already fluent in Doctrine events and Symfony DI, and the API is small enough that a mid-level engineer is productive in a day. The real ramp-up cost sits with operators, not developers: SRE/on-call needs runbooks for reindex, staleness detection, and failure recovery, and the team must understand that "search is down" here means "the database is slow," which changes the incident playbook.

TPM recommendation. Low-adoption, single-maintainer, database-native search is a reasonable fit for internal or secondary search in a Symfony/Doctrine estate, provided it is wrapped behind an owned interface and launched with reconciliation and golden-query tests. It is not appropriate as the sole search dependency for a customer-facing discovery experience, and it is out of scope entirely for a Laravel/Eloquent stack.