Meilisearch & Typesense
debt(d7/e5/b5/t5)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints note automated=no and the code_pattern is a symptom (LIKE '%term%' full scan, MySQL FULLTEXT at limits) that only surfaces under load or careful review. Laravel Scout is listed as a tool but it doesn't flag 'you should be using Meilisearch instead' — it only helps once you've already made the switch. Degraded search relevance or missing typo-tolerance is silent in normal development until users complain.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix describes swapping to Meilisearch/Typesense, but the common_mistakes reveal that misconfiguration (filterable/sortable attributes, indexable fields, attribute priority) requires re-indexing, queue worker setup, and schema decisions. This is more than a one-line patch — it involves infrastructure setup, model changes, queue integration, and index configuration across the application.
Closest to 'persistent productivity tax' (b5). applies_to covers web and api contexts broadly. Once adopted, the search engine becomes a dependency every future developer must understand: index configuration, re-indexing on schema changes, queue workers for updates, and devops concerns (self-hosted). It affects multiple workstreams (backend, devops, data modeling) but doesn't define the entire system shape.
Closest to 'notable trap (a documented gotcha most devs eventually learn)' (t5). The misconception is that Elasticsearch is required for production search, leading teams to over-engineer or avoid adding search altogether. The common_mistakes reveal additional traps: real-time indexing blocking requests, and needing to configure filterable/sortable attributes before indexing (re-indexing required if missed). These are documented gotchas that experienced developers learn but are non-obvious to newcomers.
Also Known As
TL;DR
Explanation
Meilisearch (Rust, MIT license) and Typesense (C++, open core) are modern search servers optimised for developer experience. Both provide: BM25 relevance ranking, typo-tolerance, faceting and filtering, geosearch, and sub-50ms response times. Meilisearch has a simpler API and easier setup; Typesense has stronger multi-tenancy support. Both have official PHP SDKs. For most PHP applications needing search, either is a better choice than Elasticsearch due to lower operational overhead and simpler configuration.
Common Misconception
Why It Matters
Common Mistakes
- Indexing data in real-time on every write — batch index updates in a queue worker to avoid blocking requests.
- Not configuring filterable and sortable attributes before indexing — adding them later requires re-indexing.
- Storing all document fields in the search index — only index searchable fields; store others in your DB.
- Not setting searchable attributes priority — title should rank higher than body text.
Code Examples
// LIKE search — slow, no relevance, no typo tolerance:
$results = $pdo->query(
"SELECT * FROM glossary WHERE term LIKE '%" . $db->escape($q) . "%'
OR body LIKE '%" . $db->escape($q) . "%'"
)->fetchAll();
// Issues: no ranking, O(n) scan, no typos, injection risk// Meilisearch PHP SDK:
$client = new \Meilisearch\Client('http://localhost:7700');
$index = $client->index('glossary');
// Index a term:
$index->addDocuments([[
'id' => $term['slug'],
'term' => $term['term'],
'short' => $term['short'],
'category' => $term['category'],
]]);
// Search:
$results = $index->search($query, [
'limit' => 20,
'filter' => 'category = security',
'sort' => ['term:asc'],
]);
// Typo-tolerant, ranked, facetable — 5ms response