Originally published at hafiz.dev
Laravel Scout gives you full-text search on your Eloquent models with one trait and a config value. What it doesn't give you is an opinion. The docs list five drivers (Algolia, Meilisearch, Typesense, database, and collection) and treat them as interchangeable. They're not. The driver you pick decides whether search costs you nothing, a fixed monthly fee, or a bill that grows every time your product succeeds.
I've shipped Scout with three of these drivers across client projects and my own products. This post is the comparison I wish existed: what each driver actually does, what it costs at real usage levels, and a straight answer on which one to pick.
What Scout Actually Abstracts
Quick grounding for anyone who hasn't used it. Scout syncs your models to a search index automatically. Add the Searchable trait, and every create, update, and delete flows through to your search engine via model observers:
use Laravel\Scout\Searchable;
class Post extends Model
{
use Searchable;
public function toSearchableArray(): array
{
return [
'title' => $this->title,
'body' => strip_tags($this->body),
];
}
}
Searching is one line: Post::search('pgbouncer')->paginate(15). The abstraction is the whole point: your application code stays identical across all five drivers, which means the driver decision is about operations and money, not code.
One setting that isn't optional in production: 'queue' => true in config/scout.php. Without it, every model save blocks on an HTTP call to your search engine. Push index updates through your queue workers and the write path stays fast. And a detail that surprises people: even with queueing off, Algolia and Meilisearch index asynchronously on their side. Your job finishing doesn't mean the record is searchable yet. Write your tests accordingly.
The Four Real Contenders
The collection driver filters records in PHP after pulling them all from the database. It exists for local development and works everywhere, including SQLite. It's not a production option, so it's out of the comparison. That leaves four.
The database driver runs full-text indexes and LIKE clauses against MySQL or PostgreSQL. No new infrastructure, no sync problems (it queries your actual tables), no cost. Also: no typo tolerance, no relevance tuning worth the name, no facets.
Meilisearch is an open-source engine written in Rust. Sub-50ms responses, typo tolerance, faceting, and highlighting out of the box with almost no configuration. Its defaults are good enough that most projects never touch relevance settings. Self-host it free (MIT license) or use Meilisearch Cloud.
Typesense is the closest thing Meilisearch has to a twin: open-source, typo-tolerant, instant search, written in C++. It differentiates on operational predictability. Typesense Cloud gives you a dedicated cluster priced by RAM and CPU per hour, with no per-record or per-operation charges at all. It also has more mature vector and geo search than Meilisearch.
Algolia is the incumbent hosted service. The most polished dashboards, the best frontend libraries (InstantSearch), AI re-ranking, and enterprise features nobody else matches. You pay for it with usage-based pricing that scales with your traffic.
Feature Comparison: Where They Actually Differ
On core search quality (typo tolerance, prefix matching, ranking) Meilisearch, Typesense, and Algolia are closer than their marketing suggests. All three return results in tens of milliseconds and handle "labrvel" finding "laravel" without configuration. For a typical SaaS search box, users can't tell them apart.
The differences live at the edges. Algolia leads on merchandising and AI features: synonyms management, A/B testing relevance, personalization. If you're building e-commerce search where a 2% conversion lift pays for the tooling, that matters. Typesense leads on vector search and its Search Delivery Network, which replicates your index across regions like a CDN. Meilisearch leads on getting to good results with the least configuration of the three.
The database driver isn't playing the same sport. It matches words, roughly in the order your database returns them. Search for "posgres" and you get nothing, because there's no typo tolerance. For a public-facing product search, that's disqualifying. For an admin panel where your team searches customers by name or email, it's completely fine, and I'd argue anything more is over-engineering.
The Money: What Search Actually Costs
This is where the comparison stops being close, so let's do real math. All prices verified this week; search providers change pricing often, so treat these as July 2026 numbers.
Algolia has a free Build tier (10,000 search requests a month) that's generous for prototyping. The paid Grow plan is pay-as-you-go: $0.50 per 1,000 search requests and $0.40 per 1,000 records beyond the included 10,000 requests and 100,000 records. Grow Plus, which adds the AI features, jumps to $1.75 per 1,000 requests.
Meilisearch Cloud starts at $30/month for the Build plan and climbs into the hundreds at the million-document tier. Self-hosting is free under MIT.
Typesense Cloud bills the cluster, not the usage: pick RAM and CPU, pay per hour it runs. The smallest configurations work out to roughly $7-25/month, and you can throw as many searches at it as the hardware handles. Self-hosting is free.
The database driver costs zero. Your database is already running.
Now the worked example. Say your app does 500,000 searches a month across 250,000 records, a realistic mid-sized SaaS:
Algolia Grow: 490,000 billable requests ($245) plus 150,000 extra records ($60) lands around $305/month. Every new user who searches makes next month's bill bigger. Meilisearch Cloud at that document count sits in its higher tiers, roughly the $200-300/month range. Typesense Cloud handles that load comfortably on a small dedicated cluster in the $25-70/month range, and the bill doesn't move when traffic doubles until the hardware runs out. Self-hosted Meilisearch or Typesense on a basic Hetzner or DigitalOcean instance: about €5-10/month for the server, and the real cost is you being the person who gets paged.
That's a 30x spread for the same feature. The pricing model matters more than the sticker price: Algolia charges you for growth, Typesense charges you for capacity, self-hosting charges you in responsibility.
When the Database Driver Is Honestly Enough
The advice you'll find everywhere is "just use Meilisearch," and it's not wrong. But I want to defend the boring option, because I keep seeing projects run a search server for workloads that don't need one.
Use the database driver when all of these are true: your searchable dataset is under roughly 100,000 rows, your users are internal or forgiving (admin panels, back-office tools, MVPs), and you're searching short fields like names, emails, and titles. MySQL and Postgres full-text indexes are fast at this scale, and a proper index is the only tuning you'll ever do. You skip a service, a sync pipeline, a deploy dependency, and a monthly bill.
Move up when users start expecting typo tolerance, when you need facets and filters on the search page, or when search becomes part of the product rather than a utility. You'll feel the moment. And because Scout abstracts the engine, the migration is a config change plus php artisan scout:import, not a rewrite. That's the quiet superpower of building on Scout even when you start on the database driver.
My Recommendation
For most Laravel apps in 2026: self-hosted Meilisearch if you already run a VPS, Typesense Cloud if you don't want to.
Meilisearch wins the self-host case because it's the least operational search server I've run: one binary, sane defaults, and it sits happily in 512MB of RAM for small datasets. If you deploy with Docker or manage a Hetzner box already, adding it costs you an evening. Typesense wins the managed case because resource-based pricing means your search bill is a known number, and known numbers are worth a lot to a bootstrapped product. A SaaS charging monthly should not have a cost line that scales per-search.
Pick Algolia when its extras are the point: merchandising tools, the InstantSearch frontend stack, AI ranking for an e-commerce catalog where relevance is revenue. It's the best product of the three and priced like it knows.
And pick the database driver more often than the internet suggests. Half the Scout setups I've reviewed could have been a full-text index.
One operational note whichever engine you choose: if you're running Octane or serious queue concurrency, keep Scout's queue on and give indexing jobs their own queue name. A bulk import re-indexing 100K models on the same queue as your password-reset emails is a bad afternoon.
FAQ
Can Laravel Scout do semantic or vector search?
Scout itself is engine-agnostic, so it depends on the driver. Typesense has the most mature vector search of the three engines; Meilisearch's is newer and improving fast. If semantic search is central to your product, that's a different architecture conversation than a search box, and I've covered the options in my guide to full-text, semantic, and vector search in Laravel.
Which Scout driver is fastest?
For end-user perception, Meilisearch, Typesense, and Algolia are all effectively instant (tens of milliseconds) on typical datasets. The database driver is fast at small scale and degrades as tables grow and queries lean on LIKE. If you're choosing between the three engines on latency alone, you're optimizing the wrong variable; choose on cost model and features.
Does switching Scout drivers require code changes?
Almost none, and that's Scout's best feature. Your models, toSearchableArray(), and search calls stay the same. You change SCOUT_DRIVER, add the new engine's credentials, and run php artisan scout:import to build the index. The exceptions are engine-specific features like Typesense's schema definitions or Algolia-specific query options, which you'd need to recreate or remove.
Is the database driver production-ready?
Yes, within its limits. It uses real full-text indexes on MySQL and PostgreSQL rather than naive LIKE scans, and it can't drift out of sync because it queries your actual tables. What it lacks is typo tolerance, ranked relevance, and facets. Internal tools and small catalogs: absolutely. Public product search where users type fast and expect Google-ish forgiveness: use a real engine.
Do I need Scout at all, or can I use Meilisearch directly?
You can use any engine's SDK directly, and for complex multi-index setups some teams do. Scout earns its place through the automatic model syncing and the driver abstraction that makes engines swappable. For the common case of "make these models searchable," writing your own sync layer is reinventing a wheel Scout ships for free.
Wrapping Up
Scout's driver choice is a cost-model choice wearing a technical costume. The database driver is free and underrated for internal tools. Self-hosted Meilisearch is the sweet spot for developers who already run servers. Typesense Cloud buys you a predictable bill. Algolia buys you the most product for the most money, priced per unit of your own growth. Start boring, and let Scout's abstraction make the upgrade a config change instead of a project.
Setting up search for a Laravel app, or trying to cut an Algolia bill that grew faster than revenue? I've done both and I'm happy to talk through your setup. Get in touch.
Top comments (0)