- What does matchish/laravel-scout-elasticsearch do?
- It is an Elasticsearch engine for Laravel Scout that replaces Scout's default engine with an Elasticsearch backend. It keeps Scout's model-based API while adding full-text search, filtering, aggregations, and cross-model queries. The main differentiator is a Search facade and its own Searchable trait for querying multiple indices in one request.
- How do I install and configure it with Laravel Scout?
- Install it with composer require matchish/laravel-scout-elasticsearch, then set Scout's driver to elasticsearch in config/scout.php and provide your Elasticsearch connection settings. Models using Laravel Scout's Searchable trait become indexable with that configuration change. The multi-model path is additive and uses the package's own Searchable trait and Search facade.
- Does it support searching across multiple models at once?
- Yes. The package provides a Search facade and its own Searchable trait so you can query several indices in one logical request and merge results into a single ranked, paginated set. This is the capability Scout does not provide natively and is the package's main reason to exist. Be careful with trait imports because it shadows Scout's Searchable trait with a same-named trait from a different namespace.
- Which Laravel, Scout, PHP, and Elasticsearch versions are supported?
- The package is historically oriented toward Elasticsearch 7.x, so you should confirm the exact support matrix before committing. Verify Laravel, Scout, PHP, Elasticsearch 7.17 versus 8.x, and OpenSearch compatibility explicitly with the maintainer or a spike. Do not assume current Scout majors are supported just because a recent release exists.
- Can I use it with Elasticsearch 8 or OpenSearch?
- Elasticsearch 8 is a significant risk because it defaults to TLS and authentication, removes mapping types, and enforces stricter client compatibility headers. Elasticsearch-php major-version pinning is also a likely source of hard blockers. Confirm Elasticsearch 8 and OpenSearch support explicitly before designing around either.
- How does cross-index pagination work, and what about max_result_window?
- Merging ranked results across multiple indices requires over-fetching from each index, so page k implies fetching from-plus-size per index. This interacts with index.max_result_window, which defaults to 10,000, and makes deep pages expensive or impossible. There is no clean search_after story across heterogeneous index schemas, so treat this as a functional ceiling to design around.
- Does per-model Scout search still work alongside the multi-model path?
- Yes, the package registers itself as Scout's elasticsearch driver, so models already using Laravel Scout's Searchable trait can remain indexable with a configuration change. The multi-model path is additive and non-standard, which means your codebase may have two search idioms: Model::search() and Search::search(A::class, B::class). Confirm the behavior in your app before relying on both paths side by side.
- Are aggregations, highlighting, and suggestions exposed through the multi-model API?
- The package describes filtering and aggregations and delegates query execution to Elasticsearch, but you should verify what the multi-model Search facade actually exposes. The key question is whether aggregations, highlighting, and suggestions are available through that API or whether it returns only hits. Test the specific query features your product needs before committing.
- Is matchish/laravel-scout-elasticsearch actively maintained?
- It is MIT licensed with a small maintainer set, roughly 742 stars, and 0 Packagist dependents, so ecosystem validation is thin. The registry shows a recent release dated 2026-05-29, but low dependent count means little external pressure to keep pace with Laravel and Scout majors. Confirm release cadence and maintainer responsiveness, and assume a fork may be needed.
- How do I handle mappings and reindexing without downtime?
- Index and mapping management tooling is thinner than the query side, so verify whether alias-based reindexing, dual-write, and atomic swap are supported. Also confirm whether search:import-style backfill is resumable before assuming production readiness. If a mapping change requires downtime in your setup, plan that operational risk explicitly.