Elastic Scout Driver Plus Laravel Package

Product Decisions This Supports

• Search & discovery roadmap. This is an enabling layer, not a product in itself. It sits on top of Laravel Scout + the Elastic Scout Driver and unlocks the search capabilities that a basic Scout integration can't deliver: relevance-tuned querying, filtering/faceting, and richer result shaping. Adopting it is a prerequisite decision for any roadmap item that depends on "search that actually works" (site search, catalogue discovery, marketplace listings).
• Self-hosted search vs. managed SaaS (build vs. buy). The core PM trade-off this package sits inside: run Elasticsearch yourself (or on Elastic Cloud) under Laravel's native model abstractions, versus paying per-record/per-search to Algolia or similar. Choosing this package is effectively choosing the "own the cluster, own the relevance" path — cheaper at scale, more expensive in engineering time.
• Zero-downtime reindexing as a product capability. Features that change indexed data constantly — price updates, inventory, content publishing, moderation state changes — need reindexing that doesn't take search down. Whatever subset of that the extension provides, it directly determines whether you can promise "search stays live during backfills" in your SLOs and release process.
• Multi-locale / multi-tenant / multi-index segmentation. Splitting indices per language, region, or tenant is a product decision (marketplace expansion, regional catalogues, B2B tenant isolation) that the base driver doesn't handle gracefully. This package is what makes that decision cheap to implement rather than a bespoke service.
• Geo-aware experiences. Store locators, "near me," delivery-zone filtering, local inventory — these depend on geo queries and distance sorting, which is exactly the class of feature an "extension" package exists to add.
• Platform standardization. If multiple product squads are building search, deciding "all Laravel search goes through Scout + Elastic drivers + this extension" is an architecture decision with real long-term consequences for hiring, onboarding, and incident ownership.
• Sequencing the relevance investment. Relevance tuning is iterative and requires index-level control (mappings, analyzers, custom fields). Committing to this package is committing to owning that tuning loop rather than treating search as a black box.
• Framework upgrade cadence as a planning input. Release v7.0.0 adds Laravel 13.x and Scout 11.x support — meaning the package's major versions track the framework's major versions. That's good news for longevity, but it means "upgrade Laravel" and "upgrade the search extension" become one work item, not two.

When to Consider This Package

Consider it when:

• You're already on Laravel + Scout, and the team has accepted Elasticsearch as the search backend (self-managed or Elastic Cloud). This is an add-on — it presupposes the base Elastic Scout Driver is in place.
• Your requirements have outgrown what Scout's built-in driver surface gives you: multiple indices per model, per-locale/per-tenant splitting, zero-downtime reindexing, geo queries, custom index settings and mappings.
• You have meaningful data volume or query complexity — enough that per-record SaaS pricing or per-query costs become a budget line item, or where you need control over analyzers and relevance that a managed black box won't give you.
• You have (or can hire) someone who can operate Elasticsearch: capacity planning, version upgrades, cluster health, backup/restore, index lifecycle. This is the single biggest hidden cost.
• Data residency, compliance, or "search data stays in our infrastructure" is a hard requirement.
• You're comfortable with a small, community-maintained dependency — 286 stars, MIT, essentially single-maintainer territory — and you're willing to vendor or wrap it if it goes quiet. The v7.0.0 release (Laravel 13 / Scout 11) is reassuring evidence that the maintainer is keeping pace with the current framework line rather than letting it drift.
• You're planning to be on current Laravel/Scout versions. The package's support window effectively moves with the framework's, so teams that lag several majors behind should check compatibility before committing.
• You need to integrate search inside the app's domain model (Eloquent models, observers, existing deployment pipeline) rather than running a separate indexing service.

Look elsewhere when:

• You don't want to run Elasticsearch. If nobody wants to own a cluster, a managed offering (Algolia, Typesense Cloud, Meilisearch Cloud) is almost always the better product decision, even at higher per-record cost. There are Scout drivers for Meilisearch and Typesense that sidestep this entirely.
• Your corpus is small — roughly tens of thousands of records with simple search needs. Postgres full-text, LIKE-with-trigram, or a managed service will be cheaper in total cost of ownership than a cluster plus an extension.
• You need out-of-the-box relevance analytics, A/B testing, merchandising rules, or a business-user UI for tuning. This package gives engineering control, not a merchandiser's console. That's a different purchase.
• Your team isn't PHP/Laravel-native for search, or you're planning to move search to a dedicated service/team. In that case you're buying into a coupling that will be unwound later.
• You need vendor-supported SLAs. This is MIT, community-maintained; there is no support contract. If search is revenue-critical and you can't absorb maintainer risk, negotiate that explicitly (internal fork, dedicated owner, or a paid alternative).
• Version-alignment risk is unacceptable. Extension packages trail both Laravel and Elasticsearch releases, and major versions are coupled: v7.0.0 is the Laravel 13 / Scout 11 line, while the prior major serves the Laravel 12 / Scout 10 line. Also note that Scout 11 support does not by itself imply a change in supported Elasticsearch server versions — confirm that separately if you're upgrading the cluster. If you run bleeding-edge versions of any of the three, budget for compatibility work.

How to Pitch It (Stakeholders)

For executives (one paragraph): We're evaluating a free, open-source add-on for our Laravel application's search layer. It lets us run search on our own Elasticsearch infrastructure while getting the features our product roadmap actually needs — fast, filtered, geo-aware results, plus the ability to rebuild indexes without taking search offline. The strategic case is cost and control: at our data volume, per-record managed-search pricing grows faster than our infrastructure bill, and owning the index means we own relevance tuning, data residency, and the ability to change search behavior without a vendor negotiation. The trade-off is real: we take on the operational burden of running Elasticsearch and depend on a small community project. The latest release (v7.0.0) adds support for the current Laravel and Scout versions, which is a positive signal on maintenance — but it also shows the package's major versions move in lockstep with the framework's, so framework upgrades will carry a search-upgrade line item. That's an engineering-capacity commitment, not a licensing cost — and it should be approved as such.

For engineering leadership: It's an MIT-licensed extension to the Elastic Scout Driver, so it composes with the standard Laravel/Scout/Eloquent patterns our teams already know — no new language, no separate indexing service, no bespoke event pipeline. It's aimed squarely at the gaps in the base driver (multi-index segmentation, reindexing, geo, index configuration). The v7.0.0 release adds Laravel 13.x and Scout 11.x support, which tells us the maintainer is tracking current framework releases rather than letting the package go stale — but it also confirms the coupling: major versions align with Laravel/Scout majors, so the previous major is the one to use if we're still on Laravel 12 / Scout 10, and upgrading the framework means upgrading this package in the same cycle. Plan around two caveats: it's community-maintained with a single dominant maintainer (~286 stars), so treat it as a dependency we may need to fork and own; and verify Elasticsearch server version support independently, since this release says nothing about the cluster side. Recommendation: spike it against one real search surface, measure the ops cost of the cluster it implies, and decide with that number in hand rather than on feature-list grounds.