Search Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for search: This package is the "build-lite" option — it delivers full-text search over Doctrine entities with zero external services. It directly competes with the "buy" options (Algolia, Elasticsearch/OpenSearch, Meilisearch, Typesense) on cost and operational simplicity, which makes it a viable line item in a build-vs-buy evaluation rather than an automatic infrastructure purchase.
• Feature scoping for v1 search: If the roadmap item is "users can search records in the admin/backoffice," this package can satisfy the requirement without a search infra workstream. That frees the search epic to ship in a normal sprint instead of a cross-team platform project.
• Roadmap sequencing: Because it removes the dependency on standing up and operating a search cluster, search can be moved earlier in the roadmap for internal tools, CMS/backoffice, and MVP products where search is table stakes but not a differentiator.
• Deferring infrastructure investment: Justifies postponing a dedicated search platform (and the SRE/ops headcount it implies) until relevance tuning, scale, or multi-language requirements actually materialize. Search quality becomes a "revisit when metrics demand it" decision rather than a launch blocker.
• Total cost of ownership comparisons: Useful counterfactual in TCO models — no managed-search subscription, no index sync pipeline, no second datastore to back up, monitor, and secure.
• Use cases it fits: internal admin search, entity lookup/autocomplete, small-to-medium catalogs, single-tenant or low-QPS applications, and on-prem/air-gapped deployments where adding a third-party SaaS or a JVM cluster is a compliance or procurement non-starter.

When to Consider This Package

Consider it when:

• The domain model is Doctrine ORM entities — this is a Symfony bundle built around Doctrine, so it fits Symfony/Doctrine applications, not Eloquent-based Laravel apps. Confirm your stack before shortlisting.
• No external dependencies is a hard requirement: air-gapped, regulated, on-prem, or data-residency-constrained environments where shipping data to a search SaaS is disallowed.
• Search is supporting, not differentiating — "find the record" rather than "relevance is the product."
• You want to avoid operating a search cluster and your data volume fits comfortably in the primary database.
• You need a cheap proof of concept to validate a search feature before committing to a platform.

Look elsewhere when:

• You're on Laravel/Eloquent. The natural equivalents are Laravel Scout with a database or TNTSearch driver, or Postgres full-text search. Adopting a Doctrine-centric bundle in an Eloquent codebase means fighting the grain.
• Adoption risk is unacceptable. 11 stars and 0 dependents is a genuine signal: no community, no ecosystem of fixes, unclear long-term maintenance, and a single point of failure for a core feature. Treat this as a vendored dependency you may need to fork and own.
• You need relevance as a product: typo tolerance, synonyms, faceting, boosting, highlighting, multi-language stemming, fuzzy matching, learning-to-rank.
• Scale or query load exceeds the primary database's comfort zone — DB-resident full-text search competes with your transactional workload.
• You need faceted/vector/hybrid search or plan to expose search to high-QPS customer-facing traffic.
• Procurement or security review requires a supported vendor, SLA, or security-response process.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed library that adds search to our application without buying or operating any external search service. Translation: no new vendor contract, no new infrastructure, no new on-call surface, and no data leaving our environment — which matters for compliance and for our cloud bill. It lets us ship the search items on the roadmap in a normal sprint rather than as a platform project. The trade-off is maturity: it has a very small community, so we should treat it as "adopt with a spike and an escape hatch," not "bet the product on it." Recommend a bounded pilot on an internal, low-risk surface, with a defined review date and an abstraction layer so we can swap in a managed search engine later without rewriting features.

To engineering: Doctrine-native, dependency-free full-text search — no Elasticsearch cluster, no index-sync pipeline, no second datastore to secure and back up. It moves search cost into the database we already run and operate. Before we commit, we want a time-boxed spike to validate indexing performance, query latency at realistic data volumes, and behavior on updates/deletes. Two conditions for adoption: (1) we put search behind an internal interface so the backend is swappable, and (2) we accept that with ~11 stars and no dependents we may end up owning a fork. If either condition can't be met, the fallback is Postgres full-text search or a Scout-compatible driver — comparable effort, less ownership risk. Note the stack check: this is Doctrine-oriented, so it's a direct fit for Symfony services but the wrong shape for Eloquent models.