Sqlout Laravel Package

Product Decisions This Supports

• Shipping search without buying search infrastructure. This package lets a Laravel team deliver keyword-relevance search on top of the MySQL instance the product already runs, instead of standing up Algolia, Meilisearch, Typesense, or Elasticsearch. That is a "ship the feature this quarter, defer the platform investment" decision, and it is still the single most valuable use of this assessment.
• Build vs. buy vs. adopt. The realistic choice is three-way: build a bespoke MATCH … AGAINST layer against MySQL, buy a managed search service, or adopt a Scout driver like this one. This package makes the third option viable and materially cheaper than the first, because it removes the adapter code you would otherwise own and maintain.
• Roadmap sequencing. It supports a deliberate "search v1 now, search platform later" roadmap: launch relevance-ranked search in an MVP or internal tool, then revisit when query volume, catalog size, or relevance requirements cross a threshold. Scout's driver abstraction means the migration later is a configuration change plus reindexing, not a rewrite — that optionality is the core PM argument.
• Cost and vendor decisions. Zero incremental infrastructure, zero per-search or per-record pricing, no new vendor in the procurement and security-review pipeline. For a cost-constrained team or an app with modest search needs, this can be the difference between shipping search and not shipping it.
• Data residency and compliance posture. Search queries and indexes stay inside the primary database. For products with data-locality requirements, or customers who object to a third party indexing their content, this removes an entire category of review work.
• New in v5.2.0 — a credible answer to "what about tenants / multiple content types?" Models can now be indexed into different tables. That turns "all search lives in one index table" from an assumption into a choice: you can give a tenant, a content type, or a back-office corpus its own index table. For a PM this widens the set of products where the cheap option is defensible — it does not make this a multi-tenant search platform, but it removes a previously hard "no."
• New in v5.2.0 — a real tuning knob. Stopwords can be loaded from a TXT or PHP file rather than being baked in. That makes relevance tuning a configuration activity instead of a code change, and lets you hold per-language noise-word lists. It is the cheapest possible version of relevance tuning — no synonyms, no boosting UI, no A/B harness — but it is the knob you will actually reach for first.
• New in v5.2.0 — filtered search is less of a workaround. Scout's query(), whereIn(), and whereNotIn() are now respected instead of silently ignored. Practically, this means "search within the records this user is allowed to see" and "search within this category set" become expressible through the normal Scout API rather than hand-rolled. Note carefully: this is filtering, not faceted counts.
• Concrete use cases worth evaluating it against: admin and back-office search over internal records; CMS, blog, and documentation search; early-stage marketplace or catalog search; single-tenant SaaS where the dataset comfortably fits one MySQL instance; search in self-hosted or on-premise deployments where adding a service is operationally unwelcome; and now, low-cardinality multi-tenant setups where each tenant's corpus is small.
• A hedge, not a commitment. Because it plugs into Laravel Scout, adopting it does not foreclose the buy decision later. Frame it as a reversible bet with a defined trigger for reversal, not as a platform standard.

When to Consider This Package

Adopt when most of the following hold:

• The application is Laravel and either already uses Scout or can adopt it cheaply.
• The datastore is MySQL 5.7+/8.x and you control the schema, so FULLTEXT indexes can be added and maintained.
• The search corpus is small to moderate and query volume is modest — a reasonable working ceiling for MySQL FULLTEXT is on the order of hundreds of thousands to low millions of rows with low-to-moderate query rate, and no need for sub-100ms guarantees under heavy concurrency. The new multi-table indexing lets you shard the corpus across tables, which raises the practical ceiling, but it does not make a single MySQL instance behave like a search cluster.
• Requirements are keyword relevance over text fields, optionally narrowed by simple filters. That is the whole product. If the requirement is faceted navigation with counts, typo tolerance, synonyms, multilingual stemming, geospatial, or semantic/vector search, this package is the wrong tool regardless of cost. whereIn() support is a filter, not a facet.
• Write volume is moderate. FULLTEXT index maintenance adds cost to inserts and updates; a high-churn table can turn search into a write-path problem. More index tables means more indexes to maintain, so the multi-table feature trades isolation for a slightly wider write surface.
• The team has no appetite to operate a separate search cluster, and no one wants to be on call for it.
• You are prepared to treat it as a community dependency. Adoption is still very small (tens of stars, no meaningful dependent ecosystem), so there is effectively no ecosystem signal. v5.2.0 is a healthy sign of active maintenance — a package going nowhere does not ship multi-table indexing — but a release is not a support commitment. Pin the version, read the source, own a test suite around it, and keep a fork-and-maintain contingency.
• You are starting fresh on v5.2.x, or you have verified that nothing in your code calls the now-deprecated scope() method.

Look elsewhere when:

• Search is a core, differentiating product surface where relevance quality is a competitive lever. You will want tuning knobs, analytics, and A/B testing of ranking that MySQL FULLTEXT does not offer. Stopword files are not a relevance platform.
• Requirements include faceting with counts, autocomplete with typo tolerance, or multilingual stemming. These are the standard reasons teams end up buying a search service, and discovering them after launch is expensive.
• The database is Postgres, SQLite, or anything other than MySQL. Laravel ships a basic database driver for those; do not force this one.
• You need a supported vendor, an SLA, or a dependency that clears enterprise third-party review. A single-maintainer package with minimal adoption will struggle in that process, and rightly so.
• Scale or query patterns are already known to exceed what a single MySQL instance should serve, or search traffic would compete with transactional traffic on the same database.
• You need true per-tenant index isolation at scale (hundreds or thousands of tenants), granular permission-aware search across large corpora, or large-scale reindexing without downtime. Multi-table indexing helps with the shape of isolation; it does not give you zero-downtime reindex orchestration or per-tenant capacity management.

How to Pitch It (Stakeholders)

To executives: Search is a feature our users expect, and the default path — a managed search service — carries recurring cost, a new vendor, a security review, and a new system for someone to operate. This package delivers relevance-ranked search using the MySQL database we already run: no new infrastructure, no new vendor, no data leaving our environment, and we can ship it this quarter rather than next. The latest release (v5.2.0) is a meaningful one for us: it now supports separate index tables, which means we can scope search per tenant or per content type instead of cramming everything into one index, and it supports filtering search results by the user's permissions or category through Laravel's standard search API. It is a reversible decision: because it plugs into Laravel's search abstraction, if we outgrow it we change a driver and reindex, rather than rewrite the feature. The trade-off is explicit — we get keyword relevance with simple filters, not the faceting and typo-tolerance of a dedicated search product, and we are depending on a small open-source package rather than a vendor.

To engineering: This is a thin, focused adapter that implements MySQL MATCH … AGAINST as a Laravel Scout driver, so we do not write or maintain that integration ourselves. v5.2.0 is a substantive release and the first one worth reading closely before adoption:

• Multi-table indexing — models can be indexed into different tables. Useful for separating content types or tenants; design the index layout deliberately rather than letting it accrete.
• Stopwords from TXT or PHP files — moves relevance tuning into configuration. Agree who owns these files and how they are reviewed.
• Scout builder methods now honoured — query(), whereIn(), whereNotIn() were previously ignored, silently. If you evaluated this package before and concluded filters had to be hand-rolled, re-check that assumption; the earlier "filtering is a workaround" cost is gone.
• Deprecation — scope() is deprecated in favour of Scout's query(). Any prototype or pilot written against 5.1.x needs a small migration; treat the deprecated path as already-removed when planning.

The surface area is small and the escape hatch is Scout's driver interface, which means our application code stays portable. The real work is on our side and should be scoped honestly: choosing the index-table layout, adding and tuning FULLTEXT indexes, defining which columns are searchable, curating stopword lists, deciding on weighting and minimum query length, handling index rebuilds, and writing tests around relevance so we notice regressions. Treat the dependency as a community package — pin to 5.2.x, review the source before adoption, and confirm we are comfortable forking it if it goes unmaintained. Recommendation: pilot on one low-risk surface, such as admin search or documentation search, instrument query latency and result quality, and set a written threshold — catalog size or query volume — at which we revisit the buy decision.