Laravel Fulltext Laravel Package

Product Decisions This Supports

• Search as a v1 feature, not a platform bet. This package turns a MySQL/MariaDB FULLTEXT index into an Eloquent-friendly search layer (searchable trait, weighted columns, relevance score, boolean/wildcard queries). It lets you ship "search our catalog / customers / documents" inside a sprint rather than a quarter.
• Build vs. buy vs. borrow. It replaces roughly 1–2 weeks of custom indexing, query parsing, weighting, and result-scoring code with a small, MIT-licensed dependency. For a non-differentiating capability, that is usually the right trade.
• Roadmap sequencing. Use it as the now step on a search maturity path: MySQL FULLTEXT → Scout + Meilisearch/Typesense → managed engine (Algolia/Elasticsearch) only when relevance, scale, or latency metrics demand it.
• Platform and data-model decisions. It quietly constrains you to MySQL/MariaDB and to searchable columns you can index. That should be a conscious architecture call, not an accident, because migrating off FULLTEXT later means re-indexing and re-tuning relevance.
• Prioritization signal. If search relevance is a differentiator (marketplace discovery, semantic matching, personalization), this is the wrong tool. If search is table stakes that users expect to "just work," it is right-sized.
• Use cases it fits: internal admin/CRM lookup, documentation and blog search, SMB e-commerce keyword search, filtered record retrieval over tens of thousands to low millions of rows.
• Instrumentation decision. Adopting it should come with a measurement plan — zero-result rate, click-through, p95 latency — that acts as the trigger for the next investment.

When to Consider This Package

Adopt when:

• Your primary datastore is MySQL 5.6+ or MariaDB with InnoDB FULLTEXT available and already provisioned.
• The corpus is bounded — realistically up to low millions of rows on a single node — and search QPS is modest.
• Search is supporting functionality, not the product's core value proposition.
• Your team is Laravel-native and values zero new infrastructure, zero vendor contracts, and zero ops surface.
• You need weighted relevance, boolean search, and simple filtering quickly, with an exit ramp to Scout later.
• You want cost predictability: search runs on the database you already pay for.

Look elsewhere when:

• Your primary database is PostgreSQL or SQLite (no portable FULLTEXT; use tsvector or Scout's database driver).
• You need typo tolerance, synonyms, faceting, multilingual stemming, geo search, autocomplete at scale, semantic/vector retrieval, or per-query relevance A/B testing.
• You have strict latency SLOs, high write volume (index maintenance causes write amplification), or corpora beyond a few million rows.
• You require managed SLAs, audit trails, or vendor support — this is a 188-star, effectively single-maintainer project, so bus factor is a real risk. If you adopt it, wrap it behind your own SearchService interface with contract tests so swapping to Scout + Meilisearch is a contained change.
• Your CI runs on SQLite. FULLTEXT will not exist there, so plan for a MySQL service in the test pipeline from day one.

How to Pitch It (Stakeholders)

To executives: We can deliver working search in days instead of weeks, with no new vendor, no new infrastructure, and no incremental cloud spend — it runs on the database we already operate. It is MIT-licensed and small enough to audit. Search is table-stakes for our users but not our moat, so the goal is a credible, low-cost implementation now, with a clean upgrade path to a dedicated search engine if usage data proves it is worth the investment. The main risk is dependency size and maintenance: we mitigate by isolating it behind an internal interface, so replacing it later is a contained engineering task rather than a rewrite.

To engineering: It is a thin Eloquent trait plus FULLTEXT indexes — low cognitive overhead, no new service to operate, no new deployment topology. Expect to manage the known MySQL FULLTEXT caveats: minimum token length, stopwords, no substring matching without boolean wildcards, index rebuild cost on large tables, and write amplification on hot tables. Plan for a MySQL-backed test environment, a migration/index strategy for existing data, and a SearchService abstraction with contract tests and a feature flag so we can swap in Laravel Scout + Meilisearch without touching call sites. Track zero-result queries and latency from day one; those metrics are the decision gate for the next step.