- Start with your database: MySQL and PostgreSQL full-text search is enough for many admin panels and internal tools.
- Add a search engine when users need typo tolerance, instant results as they type, or filters with counts.
- Meilisearch and Typesense can be self-hosted or used as a cloud service; Algolia is a hosted platform.
- Keep the index in sync through queued jobs, and expect a short delay before changes appear in results.
- Never index more than search needs, and filter every query by the user or customer account.
Which search option should your app use?
Start with your database. MySQL and PostgreSQL full-text search handles admin panels, internal tools and many customer apps well. Move to a search engine such as Meilisearch, Typesense or Algolia when users need typo tolerance, results that update as they type, or filters with counts across large catalogues. The engine you pick then depends on whether you want to host it yourself and how much data it has to hold.
Search is one of the features people judge an app by in the first minute, so it is worth choosing deliberately. This is how our custom software team approaches it.
When is database search enough?
Plain LIKE queries are not real search. PostgreSQL's documentation points out that they have no linguistic support, so a search for "satisfy" misses "satisfies", and they provide no ranking of results. Full-text search fixes both: it reduces words to their base forms, skips common stop words and ranks matches.
Laravel Scout's built-in database engine uses MySQL and PostgreSQL full-text indexes and LIKE clauses on your existing tables, with no separate indexing step. Laravel's documentation describes it as the simplest and most practical option for many applications. For misspellings, PostgreSQL's pg_trgm extension compares strings by shared three-letter chunks, with a default similarity threshold of 0.3.
Database search is usually enough when users search by names, emails, order numbers or short titles, when they know roughly what they are looking for, and when there are thousands of records rather than millions.
When do you need a dedicated search engine?
- Typo tolerance. Customers misspell product names and people's names, and expect results anyway.
- Search as you type. Results that update with each keystroke need very fast responses.
- Filters with counts. Faceted navigation, such as "Size: M (24)", is hard to make fast in a general database.
- Relevance you can tune. Boosting in-stock items, newer content or exact matches.
Scout's documentation names the same reasons for its Algolia, Meilisearch and Typesense drivers: typo tolerance, faceted filtering and geo-search.
How do Meilisearch, Typesense and Algolia compare?
| Engine | Hosting | Typo tolerance by default |
|---|---|---|
| Meilisearch | A single binary you can self-host, or Meilisearch Cloud | One typo for words of five or more characters, two from nine |
| Typesense | Open source, self-hosted or Typesense Cloud | One typo from 4 characters, two from 7 |
| Algolia | A hosted platform you send records to through its API | On for languages written with letters; not applied to Chinese or Japanese |
Two practical differences matter for budgets. Typesense keeps the whole search index in memory, and its documentation suggests RAM of about 2 to 3 times the size of the fields you search on. Algolia is only available as a hosted service, so you are paying for operations you would otherwise do yourself. Read each vendor's pricing page on the day you decide; plans change often. If you self-host on AWS, our guide to AWS costs for a small SaaS shows where that server will appear on the bill.
How do you keep the search index in sync with your data?
Every change to a searchable record has to reach the index. Scout does this with model observers, and its documentation strongly recommends running the sync through a queue for any external engine, so saving a record does not wait on the search service. It also warns that Algolia and Meilisearch index asynchronously, so new records may take a moment to appear in results. Design screens with that in mind, for example by showing a newly created item directly instead of relying on a fresh search.
Plan for full re-indexing too: after changing which fields are searchable, or after restoring the database, you need a command that rebuilds the index from scratch. Our guide to background jobs and queues covers the workers this depends on.
How do you test search before launch?
Build a list of real searches before you build the feature. Take them from support emails, sales calls, the old system's logs or a quick session watching people use a prototype. Include misspellings, partial words, plurals, codes such as order or product numbers, and the names of things in the words customers use, which are rarely the words in your database.
Run the same list against each option you are considering and compare the first few results, not just whether something was found. After launch, log searches that return nothing and review them every few weeks. Those empty searches show you missing synonyms, missing content and fields that should be searchable, and they are the best evidence for when it is time to move from database search to an engine.
How do you stop search showing data people should not see?
By default Scout sends the whole toArray form of a model to the index, which can include fields such as internal notes or contact details. Define exactly what gets indexed, and leave out anything search does not need.
In a multi-customer app, every query must also be filtered by the customer account and, where it applies, by the user's permissions. Test this the way an attacker would: sign in as one customer and search for another customer's record names. If search keys are used in the browser, make sure they can only search, never write, and are limited to the right data. For Laravel apps, this is standard work for our Laravel development team, and our comparison of Laravel and Node.js back ends covers the wider stack choice.
Frequently asked questions
Do we need a search engine in the first version of the app?
Usually not. Ship the first version with database search on the fields people actually look up, watch what users type, and add a search engine when the logs show misspellings, empty results or slow queries. Switching later is manageable if search sits behind one part of your code rather than being spread across the app.
Can search work in Arabic, Chinese or Japanese?
Yes, but test it with real text before you choose a tool. Language support differs: PostgreSQL relies on dictionaries for each language, and Algolia applies typo tolerance only to languages written with letters that represent sounds, not to Chinese or Japanese. Right-to-left languages also need the search box and results to be designed for that direction.
Can users search inside PDFs and uploaded documents?
Only after the text has been pulled out of the files. That means an extraction step, often in a background job, that saves the text so it can be indexed. Scanned documents need text recognition first. Plan the extraction with the upload feature, because adding it later means processing every old file again.
What about AI or semantic search?
Semantic search matches meaning rather than exact words, so a search for "refund" can find "money back". Meilisearch offers hybrid search that combines keyword and semantic results, and Algolia supports keyword, vector and hybrid retrieval. For answering questions from your content in sentences, see our guide to AI chatbots that answer from your own content.
Who should pay for and host the search service?
Decide it like any other part of the infrastructure. A cloud service means a monthly bill and less operations work; self-hosting means a server to run, update and back up. Put the account in the business owner's name, not a developer's, so access survives a change of team.
Last updated