Laravel Scout Elasticsearch Laravel Package

Technical Evaluation

Architecture fit The package is a Scout engine implementation plus an opinionated orchestration layer on top. Two capabilities matter:

1. Driver substitution — it registers itself as Scout's elasticsearch driver, translating Scout's Engine contract (update, delete, search, paginate, mapIds) into elasticsearch-php calls. Any model already using Laravel\Scout\Searchable becomes indexable with a config change.
2. Cross-model search — the real differentiator. It introduces its own Searchable trait and Search facade to query several indices in one logical request and merge results into a single ranked, paginated set. This is what Scout does not do natively and what most teams end up hand-rolling.

Architecturally this is a thin, well-scoped adapter. It does not own cluster topology, mapping lifecycle, or relevance tuning — it delegates to Elasticsearch. That is the right boundary, but it means the package is not a search platform; it is a connector with a multi-index query helper.

Integration feasibility Low effort, medium surprise risk.

• Install and wiring is a composer require plus a Scout driver config value.
• The multi-model path is additive and non-standard: it shadows Scout's Searchable trait with a same-named trait from a different namespace, and exposes a static facade rather than an Eloquent query. Teams will have two search idioms in one codebase (Model::search() vs Search::search(A::class, B::class)), and trait-import mistakes will fail silently or confusingly.
• Index/mapping management tooling is thinner than the query side. Verify whether the package ships alias-based reindexing and whether search:import-style backfill is resumable before assuming production readiness.

Technical risk

• Elasticsearch version coupling (highest risk). The library is historically ES 7.x-oriented. ES 8 defaults (TLS on, authentication required, no mapping types, stricter client compatibility headers) plus elasticsearch-php major-version pinning are the most likely source of a hard blocker. Confirm the supported matrix explicitly, including OpenSearch, before committing.
• Cross-index pagination semantics. Merging ranked results across N indices requires over-fetching from each index; page k implies fetching from + size per index. This interacts with index.max_result_window (10k default) and makes deep pages expensive or impossible. There is no clean search_after story across heterogeneous index schemas. Treat this as a functional ceiling to design around, not a bug to fix.
• Schema divergence. Each searchable model contributes fields to a shared result shape; the package does not enforce a common contract. Merged relevance scores are not comparable across indices unless field mappings and boosts are harmonized — a ranking-quality risk that surfaces as "search feels wrong" rather than as an error.
• Bus factor. MIT, small maintainer set, ~742 stars but 0 Packagist dependents — thin ecosystem validation and low external pressure to keep pace with Laravel/Scout majors. Assume a fork may be needed.

Key questions for the maintainer / spike

1. Exact support matrix: Laravel, Scout, PHP, Elasticsearch 7.17 vs 8.x, OpenSearch.
2. Is zero-downtime reindexing supported (aliases, dual-write, atomic swap), or is a mapping change an outage?
3. How does pagination behave past max_result_window, and is search_after offered?
4. Are aggregations, highlighting, and suggestions exposed through the multi-model API, or only hits?
5. Does per-model Scout search continue to work unchanged alongside the multi-model path?
6. What is the release cadence and maintainer responsiveness to Scout major bumps? The registry shows a recent release (2026-05-29) but 0 dependents — confirm the project is actively maintained, not just occasionally tagged.

Integration Approach

Stack fit Strong fit for a Laravel monolith on Scout 9/10 with a genuine cross-entity search requirement (e.g., one global search box spanning articles, products, users). Weak fit if you only need single-model search — Scout's Meilisearch/database drivers plus a smaller footprint will cost less. Also a weak fit if your platform standard is OpenSearch and you need vendor-blessed support.

Migration path Treat this as a feature-scoped adoption, not a search-platform replacement.

• From the database driver: straightforward; indexable models gain Searchable, backfill via Scout's import command, keep a fallback to SQL LIKE behind a flag during rollout.
• From Algolia/Meilisearch: this is a re-platforming, not a swap. Relevance behaviour, typo tolerance, and faceting differ materially. Budget explicit relevance-acceptance testing with product, not just smoke tests.
• Keep the multi-model layer confined to the global-search surface initially. Do not let it leak into per-model list screens where Model::search() is sufficient and better understood.

Compatibility Pin matchish/laravel-scout-elasticsearch to an exact version and pin elasticsearch/elasticsearch to the cluster's minor line. Scout majors have changed Engine method signatures historically; a Scout upgrade is a package upgrade is an ES client upgrade — three lockstep dependencies. Add a CI job that boots the package against the target ES image so version skew fails in CI, not in production.

Sequencing

1. Spike (1 sprint): stand up a scratch ES cluster at the target version, install the package, index two small models, exercise multi-model search, pagination past page 5, and one mapping change. Confirm the support matrix answers empirically.
2. Contract design: define the shared field shape and per-index boosts before writing indexing code. This is the decision that is expensive to reverse.
3. Pilot: one non-critical global search surface behind a feature flag, with SQL fallback.
4. Backfill + observability: resumable import, index health checks, query latency and zero-result-rate dashboards.
5. Expand feature by feature; only then consider retiring the incumbent search path.

Operational Impact

Maintenance Ongoing cost is modest but not zero: dependency bumps ride on Laravel/Scout/ES release trains, and each bump is a potential breaking change across three libraries. Plan ~0.1–0.2 FTE steady-state plus an explicit fork readiness decision — clone, pin, and verify you can build and patch it internally. With 0 dependents and a small maintainer set, "we can fork it" must be a rehearsed capability, not an assumption. Allocate maintenance to a named owner; unowned search connectors rot quietly.

Support Community-only: GitHub issues, MIT with no warranty, no commercial escalation. Internal runbooks are a deliverable, not a nice-to-have. The bespoke multi-model API is documented at README depth, so tribal knowledge will accumulate — write it down or it leaves with the engineer.

Scaling Cluster sizing is dominated by Elasticsearch, not this package — shard count, heap, and refresh interval are your levers. What the package adds to the cost curve:

• Amplified query cost per page. One user page view becomes N index queries with over-fetch. Deep pages multiply this. Latency SLOs should be set on the merged path, not on single-index benchmarks.
• Indexing throughput is bounded by Scout's queue driver and the package's bulk behaviour. Backfills compete with live indexing; throttle them.
• Result-set ceiling at max_result_window and the absence of a cross-index cursor means you should design the UX to cap page depth (e.g., 10 pages) rather than promise exhaustive pagination.

Failure modes and mitigations

Ramp-up For a competent Laravel engineer: roughly one day to working single-model search, one week to a trustworthy pilot including mapping design, relevance sanity checks, and the alias/reindex runbook. The learning curve is not the package's API — it is Elasticsearch itself (mappings, analyzers, relevance) plus the package's non-Scout-shaped multi-model semantics. Budget the second part; it is where surprises live.

TPM verdict Worth a spike, gated on the ES 8 / Scout compatibility answers. The value proposition — multi-model search without hand-rolling _msearch merging — is real and commonly needed. The risks are entirely conventional for a small MIT connector: version coupling, a thin maintainer base, and a bespoke API that diverges from Scout's. None are disqualifying for a feature-scoped pilot with a fallback path, an alias strategy from day one, and a rehearsed fork plan. Do not adopt it as the foundation of a company-wide search platform.