Elasticquent Laravel Package

Product Decisions This Supports

• Feature decision — search vs. LIKE: Informs whether to ship real full-text search (relevance ranking, analyzers, fuzzy matching, highlighting) on top of existing Eloquent models instead of SQL WHERE ... LIKE, which degrades in relevance quality and index performance as data grows.
• Build vs. buy vs. borrow: Represents the "borrow" option — a trait-based wrapper that lets an Eloquent model be indexed into and queried from Elasticsearch with minimal new code. It competes against (a) building a custom ES integration layer, (b) adopting Laravel Scout with a first-party driver, or (c) buying a managed search SaaS (Algolia, Meilisearch Cloud, Typesense).
• Roadmap sequencing: Useful as a scoping input for a "search" epic — it demonstrates the smallest viable slice (map model → index → bulk reindex → query) and helps estimate whether search can land in one sprint or needs a dedicated workstream for index lifecycle, reindexing, and relevance tuning.
• Data architecture decisions: Forces an explicit conversation about the read path — whether search traffic leaves the primary database, how the index stays consistent (queued model events vs. scheduled full reindex), and what the source of truth is when the index drifts.
• Prioritization input for admin/internal tooling: A low-cost fit for internal search surfaces (admin panels, article/log/catalog lookup) where relevance tuning and 99.99% availability are not business-critical, freeing the team to defer a heavier search platform investment.
• Risk register entry: With a score of 0, zero listed dependents, and no star signal, it is a concrete data point for the "dependency risk" line item in any build plan — it argues for a spike-and-fork budget rather than an assumed turnkey dependency.

When to Consider This Package

Consider it when all of the following hold:

• You are on a legacy Laravel/PHP stack pinned to an older Elasticsearch cluster (roughly the 1.x–5.x era, where "mapping types" still exist — the package's own vocabulary is a compatibility tell).
• The application already uses it, or a fork of it, and replacing it is out of scope for the current quarter.
• The search surface is internal or low-stakes — no strict latency SLOs, no compliance-driven audit requirements on query behavior.
• Your team is willing and able to own the code: fork it, pin versions, patch compatibility breaks, and write your own tests around indexing and query building.
• You need a fast proof of concept to validate that ES-backed search moves a product metric before investing in a maintained integration.

Look elsewhere when:

• You need Elasticsearch 7.x/8.x or OpenSearch. Mapping types were removed in ES 7; a package framed around "types" is very likely to require substantial rework.
• You want a supported, patched dependency — zero dependents and no visible maintainer activity means no security advisories, no Laravel-version bumps, and no upstream fixes when an ES client upgrade breaks.
• You need queued, event-driven index synchronization, multi-model/multi-index search, multi-tenant permission filtering, or index alias/zero-downtime reindexing out of the box.
• Laravel Scout with the official Elasticsearch, Meilisearch, or Algolia driver covers your need — that is the default buy/build path for a Laravel team and carries a maintainer and upgrade story.
• Search is customer-facing and revenue-bearing, where relevance quality, uptime, and iteration speed justify a managed service or a dedicated integration layer.
• You are on modern PHP/Laravel and cannot afford to freeze framework upgrades to keep a search dependency alive.

How to Pitch It (Stakeholders)

To executives: This package is a shortcut, not a platform. It lets us attach Elasticsearch to our existing Eloquent models quickly, which is enough to test whether better search actually moves the metric we care about — conversion, task completion, or support-deflection — before we commit budget to a search platform. The tradeoff is explicit: the package shows no adoption signal (score 0, no dependents) and is built around an older Elasticsearch model, so it carries real maintenance risk and should not be treated as a long-term dependency. Recommendation: fund a short, time-boxed spike to prove the value of search, and treat any production adoption as "we are now maintaining a fork" — with the corresponding engineering cost — or default to Laravel Scout plus a supported driver.

To engineering: Elasticquent gives us a trait that maps model attributes to an ES type, handles index creation, bulk indexing, and a search() entry point on the model — so the initial integration is small. The catch is ownership: it is effectively unmaintained, targets an Elasticsearch generation that predates the removal of mapping types, and has no community to absorb upgrade work. If we adopt it, we pin the ES client and PHP/Laravel versions, wrap it behind our own search interface so it stays swappable, and budget for the fork. My default recommendation is to use it only as a reference for the spike, and to build the production path on Laravel Scout or a thin, well-tested Elasticsearch client service we control.