Product search

01Three levels: LIKE, full-text, search engine

The first level is a database LIKE query: WHERE name LIKE '%dog food%'. It is easy, but a leading wildcard cannot use a normal index, so it scans the table, and it has no idea about typos, word order or relevance. The second level is database full-text search: MySQL FULLTEXT indexes or PostgreSQL tsvector with GIN indexes. They split text into words, handle stemming ("running" matches "run"), and rank by relevance — good enough for blogs and small catalogues, with no extra service. PostgreSQL's pg_trgm extension adds fuzzy matching. The third level is a dedicated search engine, which builds an inverted index optimised for instant, typo-tolerant, faceted search with configurable ranking. Move up a level only when the previous one stops serving users.

1-- PostgreSQL full-text search with ranking
2ALTER TABLE products ADD COLUMN search tsvector
3  GENERATED ALWAYS AS (
4    setweight(to_tsvector('english', coalesce(name, '')), 'A') ||
5    setweight(to_tsvector('english', coalesce(description, '')), 'B')
6  ) STORED;
7 
8CREATE INDEX products_search_idx ON products USING GIN (search);
9 
10SELECT id, name, ts_rank(search, query) AS rank
11FROM products, websearch_to_tsquery('english', 'dry dog food') AS query
12WHERE search @@ query
13ORDER BY rank DESC
14LIMIT 20;

02How a search engine works

A search engine keeps an inverted index: like the index at the back of a book, it maps each word to the list of documents containing it. When you index a product, the engine tokenises the text (splits it into words), normalises it (lowercase, removes accents), and may apply stemming or language rules. At query time it looks up each word, allows a small number of typos — usually one for short words and two for longer ones, measured as edit distance — matches prefixes so results appear while typing, and ranks results. Ranking typically combines textual relevance (how many words match, how close, in which field) with business signals you configure, such as popularity, stock or margin. Facets are counts per filter value ("Brand: 12, Size: 5"), computed alongside the results.

03Choosing an engine

Algolia is a hosted service with excellent speed, typo tolerance, merchandising tools and analytics; you pay per search requests and records, which can grow expensive. Meilisearch and Typesense are open-source engines you can self-host on a small server or use as cloud services; both are fast, typo-tolerant and simple to configure, ideal for most shops. Elasticsearch and OpenSearch are powerful general-purpose engines for huge catalogues, complex queries, aggregations and logs, but they need more memory and operational expertise. In Laravel, Scout gives one API over Algolia, Meilisearch, Typesense and a database driver, so you can start simple and switch engines later.

• Small catalogue, no budget for another service: database full-text.
• Most shops: Meilisearch or Typesense, self-hosted or cloud.
• Merchandising and analytics with no ops: Algolia.
• Huge data, complex aggregations or an existing cluster: Elasticsearch / OpenSearch.

04Designing the index

A search index is not a copy of your database; it is a flattened document designed for one screen. For a shop, decide what a result is: usually a product, with its variants' attributes merged in (all colours and sizes) so filters work, and the lowest available price for sorting. Include only what search needs: name, brand, category path, attributes, keywords, price, stock flag, popularity and the image URL. Declare which fields are searchable (in priority order), which are filterable (facets), and which are sortable. Use synonyms for words customers use differently ("kitten" and "cat", "nail polish" and "lacquer"), and stop words for noise. Separate indexes for categories, brands and articles allow a rich dropdown of suggestions.

1// Laravel Scout: what goes into the search document
2class Product extends Model
3{
4    use \Laravel\Scout\Searchable;
5    public function toSearchableArray(): array
6    {
7        return [
8            'id'         => $this->id,
9            'name'       => $this->name,
10            'brand'      => $this->brand?->name,
11            'categories' => $this->categories->pluck('name')->all(),
12            'colours'    => $this->variants->pluck('colour')->filter()->unique()->values()->all(),
13            'price_min'  => $this->variants->min('price'),       // integer minor units
14            'in_stock'   => $this->variants->contains(fn ($v) => $v->available > 0),
15            'popularity' => $this->sales_last_30_days,
16        ];
17    }
18 
19    public function shouldBeSearchable(): bool { return $this->is_active; }
20}

05Keeping the index in sync

The index is a second copy of your data, so it can go stale. Update it when data changes: Scout does this automatically on model save and delete, but send the work to a queue so saving a product never waits for the search service. Watch out for changes that bypass model events — bulk SQL updates, ERP imports, stock changes in another table, or a brand rename that affects thousands of products — and trigger reindexing for the affected records explicitly. Schedule a full reindex regularly, ideally into a new index and then swap it with an alias, so users never see a half-built index. Stock and price change often; consider updating just those fields in batches rather than whole documents.

• Queue index updates; batch them for bulk imports.
• Rebuild into a new index and swap atomically.
• Alert when the number of indexed documents differs a lot from the database.

06Ranking, analytics and production tips

Good ranking is tuned, not guessed. Start with the engine's defaults, set searchable fields in order (name before description), and add a custom ranking signal such as popularity or sales. Push out-of-stock items down rather than hiding them, unless the business prefers otherwise. Log searches: the query, number of results and clicks. The list of zero-result searches shows missing synonyms, products and spelling issues; popular searches can power suggestions. Protect the search endpoint with rate limiting, and never expose admin API keys to the browser — use search-only keys, ideally scoped or time-limited. Debounce search-as-you-type on the client to about 150–300 ms, and cache popular queries.

07Relevance internals: BM25 and ranking rules

General-purpose engines such as Elasticsearch and OpenSearch score documents with BM25 by default. In plain words, a document scores higher when it contains the query terms often (with diminishing returns, so repeating a word twenty times does not help much), when the terms are rare across the whole index ("merino" counts more than "the"), and when the field is short (a match in a five-word title beats one in a long description). Field boosts multiply that score. Engines built for instant search, such as Meilisearch, Typesense and Algolia, instead use an ordered list of ranking rules or tie-breakers: number of matched words, typos, proximity, attribute order, exactness, then your custom ranking. Understanding which model your engine uses tells you what to tune: boosts and functions in BM25 engines, rule order and custom attributes in the others.

08Zero-downtime reindexing with aliases and swaps

Changing index settings — new searchable attributes, a different tokeniser, a new language — often requires rebuilding the whole index. Never do that in place, or users see half-filled results for minutes. Build a new index next to the live one, fill it in batches, check document counts and run a few smoke queries, then switch traffic in one atomic step. Elasticsearch and OpenSearch do this with aliases: the application always queries the alias "products", and an alias update moves it from products_v1 to products_v2. Typesense has collection aliases that work the same way. Meilisearch offers an index swap operation that exchanges the contents of two indexes atomically. Keep the old index for a short time so you can switch back instantly if something looks wrong.

1# Meilisearch: swap the freshly built index with the live one
2curl -X POST 'http://localhost:7700/swap-indexes' \
3  -H 'Authorization: Bearer MEILI_ADMIN_KEY' \
4  -H 'Content-Type: application/json' \
5  --data '[{ "indexes": ["products", "products_new"] }]'
6 
7# Elasticsearch / OpenSearch: move an alias atomically
8curl -X POST 'http://localhost:9200/_aliases' -H 'Content-Type: application/json' -d '{
9  "actions": [
10    { "remove": { "index": "products_v1", "alias": "products" } },
11    { "add":    { "index": "products_v2", "alias": "products" } }
12  ]
13}'

09Secure search keys and per-user filtering

Browser-side search is fast because the client calls the engine directly, but that means a key is visible to anyone. Use a search-only key, never the admin key. When results must differ per user — B2B price lists, private catalogues, a tenant's own data — do not rely on the client to add a filter, because it can simply remove it. Instead the server generates a restricted key that embeds the filter and an expiry: Algolia calls these secured API keys, Typesense scoped API keys, and Meilisearch tenant tokens, which are signed JWTs. The engine enforces the embedded filter on every query. Also index only public fields; anything in the index can be read by a determined user. Rate-limit by key or IP, and set a short expiry so leaked keys stop working quickly.

1// Meilisearch tenant token: the filter is enforced by the engine
2import { generateTenantToken } from "meilisearch/token";
3 
4export async function searchTokenFor(customer: { priceListId: number }) {
5  return generateTenantToken({
6    apiKey: process.env.MEILI_SEARCH_KEY!,       // a search-only key
7    apiKeyUid: process.env.MEILI_SEARCH_KEY_UID!,
8    searchRules: { products: { filter: `price_list = ${customer.priceListId}` } },
9    expiresAt: new Date(Date.now() + 60 * 60 * 1000), // 1 hour
10  });
11}

10Multilingual search and language edge cases

Search quality depends on how text is split and normalised, and that is language-specific. English stemming maps "boots" to "boot"; Russian and Armenian have rich word endings that need language-aware processing or prefix matching; Chinese and Japanese need segmentation because words are not separated by spaces. Mixed scripts appear too: customers type brand names in Latin script, or transliterate local words. Practical approach: store each language in its own field or index, configure the engine's language or locale settings explicitly rather than relying on detection, add synonyms between transliterations ("krem" and the Cyrillic spelling of cream), and normalise accents. Test with real queries from logs in each language, because a configuration that works well in English can quietly fail in another language.

• One searchable field per language, such as name_en and name_ru.
• Query the index for the user's interface language first.
• Treat SKUs and barcodes as exact-match fields with typo tolerance off.