If you are doing 8 seconds on simple query like that, your whole application will be as slow as mud.
SQL databases have full text search options. So creating a document like you do for Elasticsearch and use that as the search index will get you faster results. LIKE or IN are not meant as a fast search, in Mysql MATCH AGAINST is the way to go.
While a search specific database does have more features, to improve search when you need to scale up it is better to learn about the features the current database you work with offers.
Thanks for your feedback! I respect your perspective, but I have to respectfully disagree based on real production experience. Let me address your points:
"If you're doing 8 seconds on simple query, your whole application will be slow"
This is a common misconception. Search queries are fundamentally different from transactional queries:
Transactional queries (CRUD operations): 5-50ms ✅
Complex search with multiple LIKE operators on 500k+ records: 3-8 seconds ❌
The application itself runs perfectly fine. The search is the specific bottleneck because MySQL isn't designed for full-text search at scale.
"MySQL has MATCH AGAINST - use that instead"
I actually mention MySQL Full-Text search in my performance comparison table:
MySQL Full-Text: 2,100ms
Elasticsearch: 47ms
Yes, MATCH AGAINST is 44x slower than Elasticsearch in my real-world tests. Why?
Full-text indexes in MySQL have limitations:
Minimum word length (default 4 chars) - "USB" won't be indexed
No typo tolerance out of the box
Limited relevance scoring options
Struggles with phrase searches and complex boolean queries
Scaling issues:
Full-text indexes grow large and impact write performance
Rebuilding indexes on large tables locks the table
Limited to single-server scaling
Feature gap:
No fuzzy matching (typo tolerance)
No aggregations/facets (filter counts)
No custom analyzers (language-specific stemming)
No distributed search
"Learn about features your current database offers"
I agree with this philosophy for most use cases! But search is a specialized domain where using a specialized tool makes sense.
Think about it this way:
You could store images as BLOBs in MySQL... but you use S3/CDN
You could cache in MySQL... but you use Redis
You could do full-text search in MySQL... but Elasticsearch exists for a reason
When MySQL Full-Text is enough:
< 100k records
Simple keyword matching
No typo tolerance needed
No complex relevance tuning
English-only content
When you need Elasticsearch:
100k records (scaling)
Sub-100ms response times required
Typo tolerance ("wireles hedphones")
Advanced relevance scoring
Multilingual search
Faceted search with aggregations
Analytics on search behavior
The article is aimed at developers who've already hit MySQL's search limitations. If MySQL Full-Text works for you - great! Use it. But when you have 500k+ products, users expect instant results, and you need features like typo tolerance, Elasticsearch isn't overkill - it's the right tool.
Real-world proof: Companies like GitHub, Stack Overflow, Netflix, and Uber all use Elasticsearch for search despite having excellent DBAs who know MySQL inside-out. It's not because they don't know about MATCH AGAINST - it's because specialized tools win at scale.
Complex search with multiple LIKE operators on 500k+ records: 3-8 seconds
I don't doubt you got those results. The thing I was addressing is the example query. If that query needs 3 to 8 seconds there is a problem with the database.
I can see how more complex queries might slow things down substantially.
Yes, MATCH AGAINST is 44x slower than Elasticsearch in my real-world tests
I'm not going to dispute that. I mention it because you mention in the beginning and at the end using LIKE as a way to do search with a SQL database. If there are people that are using LIKE they don't understand the consequences of a search.
The point I was trying to make is that the post takes an uninformed way to doing search, and you used least search prepared database to compare Elasticsearch against.
I think the post has a lot of valuable information. I just wanted to point out the skewed comparison.
Thanks for the feedback, but I think you're missing some important context here.
You're right that LIKE shouldn't be used - that's literally the point of the article
The opening example with LIKE queries isn't presented as "the right way to do MySQL search" - it's explicitly labeled as "What we all start with (and regret)" and "The Nightmare Before Elasticsearch." It's a cautionary tale, not a recommendation.
The comparison isn't actually skewed
You say I'm comparing against "the least search prepared database," but:
The performance table includes MySQL full-text search - it shows 2,100ms vs Elasticsearch's 47ms. That's a proper apples-to-apples comparison, and Elasticsearch is still 44x faster.
The article explicitly mentions MySQL full-text - I literally write: "You add indexes. It helps... a little. Still 3-4 seconds for complex searches."
Real-world complexity matters - The benchmarks aren't just simple searches. They include:
Multiple filters (brand, price range, rating)
Sorting by relevance
Typo tolerance
500k records with realistic query patterns
Where your criticism doesn't hold up:
"If that query needs 3 to 8 seconds there is a problem with the database"
This statement ignores reality. Even with proper full-text indexes, MySQL struggles with:
Multi-field searches with different weights
Real-time typo correction
Complex relevance scoring
Faceted search with aggregations
Concurrent search load at scale
I've run these exact tests on properly configured MySQL 8.0 with full-text indexes, InnoDB optimizations, and query caching. The 2,100ms average for complex searches is accurate.
The article's audience context
You're assuming the audience already knows about MATCH AGAINST and proper MySQL full-text configuration. But many Laravel developers don't - and that's okay! The article meets them where they are, shows them why their current approach fails, and guides them toward a solution.
If someone is already using MySQL full-text search properly and it's working fine, they're not the target audience for this article. This is for teams hitting real performance walls.
What would make your feedback more accurate:
Instead of calling the comparison "skewed," you could say: "The article could be clearer that MySQL full-text search (not LIKE) is the proper baseline for comparison, and you should try that before jumping to Elasticsearch."
You're right that LIKE shouldn't be used - that's literally the point of the article
I read the point of the post as going from LIKE to Elasticsearch. Because that are the two things that are being repeated.
With the least search prepared database statement I was thinking about Postgres with the search specific indexes and a ranking feature. Not every SQL database is build the same. So instead of going from one database type to another with a different query language, it is possible to just change to a different SQL solution.
Postgres can handle more than Mysql when it comes to search.
You are hammering on the benchmark, but you are not showing the code or the database configurations. As long as the benchmarks can't be peer reviewed the result is debatable.
But In this case I have no doubt Elasticsearch it the fastest one, it is purpose build.
The comparison is skewed to favor Elasticsearch over any other solution, comparing it with LIKE statements is just one of the ways it is skewed. Don't put words in other peoples mouths.
David, I appreciate the feedback, but I think you're misinterpreting the article's intent. "Comparison is skewed"The article isn't claiming to be an exhaustive comparison of all search technologies. The title explicitly states: "Your Laravel Search Takes 8 Seconds? Here's How I Cut It to 47ms"This is a practical case study, not an academic benchmark paper. The scenario is specific:
Laravel application
500k+ records
Currently using LIKE queries (which many Laravel apps do)
Need for typo tolerance and relevance scoring
The comparison with LIKE isn't "skewed" - it's the actual problem statement. That's what the target audience is experiencing.Re: "Don't put words in other peoples mouths"I'm not putting words in your mouth. You wrote: "with the least search prepared database statement"I interpreted that as referring to LIKE queries (which is what the article discusses). If you meant PostgreSQL full-text search instead, that's a different topic - and yes, I could have mentioned it as an intermediate solution.
If you are doing 8 seconds on simple query like that, your whole application will be as slow as mud.
SQL databases have full text search options. So creating a document like you do for Elasticsearch and use that as the search index will get you faster results.
LIKEorINare not meant as a fast search, in MysqlMATCH AGAINSTis the way to go.While a search specific database does have more features, to improve search when you need to scale up it is better to learn about the features the current database you work with offers.
Thanks for your feedback! I respect your perspective, but I have to respectfully disagree based on real production experience. Let me address your points:
"If you're doing 8 seconds on simple query, your whole application will be slow"
This is a common misconception. Search queries are fundamentally different from transactional queries:
Transactional queries (CRUD operations): 5-50ms ✅
Complex search with multiple LIKE operators on 500k+ records: 3-8 seconds ❌
The application itself runs perfectly fine. The search is the specific bottleneck because MySQL isn't designed for full-text search at scale.
"MySQL has MATCH AGAINST - use that instead"
I actually mention MySQL Full-Text search in my performance comparison table:
MySQL Full-Text: 2,100ms
Elasticsearch: 47ms
Yes, MATCH AGAINST is 44x slower than Elasticsearch in my real-world tests. Why?
Full-text indexes in MySQL have limitations:
Minimum word length (default 4 chars) - "USB" won't be indexed
No typo tolerance out of the box
Limited relevance scoring options
Struggles with phrase searches and complex boolean queries
Scaling issues:
Full-text indexes grow large and impact write performance
Rebuilding indexes on large tables locks the table
Limited to single-server scaling
Feature gap:
No fuzzy matching (typo tolerance)
No aggregations/facets (filter counts)
No custom analyzers (language-specific stemming)
No distributed search
"Learn about features your current database offers"
I agree with this philosophy for most use cases! But search is a specialized domain where using a specialized tool makes sense.
Think about it this way:
You could store images as BLOBs in MySQL... but you use S3/CDN
You could cache in MySQL... but you use Redis
You could do full-text search in MySQL... but Elasticsearch exists for a reason
When MySQL Full-Text is enough:
< 100k records
Simple keyword matching
No typo tolerance needed
No complex relevance tuning
English-only content
When you need Elasticsearch:
100k records (scaling)
Sub-100ms response times required
Typo tolerance ("wireles hedphones")
Advanced relevance scoring
Multilingual search
Faceted search with aggregations
Analytics on search behavior
The article is aimed at developers who've already hit MySQL's search limitations. If MySQL Full-Text works for you - great! Use it. But when you have 500k+ products, users expect instant results, and you need features like typo tolerance, Elasticsearch isn't overkill - it's the right tool.
Real-world proof: Companies like GitHub, Stack Overflow, Netflix, and Uber all use Elasticsearch for search despite having excellent DBAs who know MySQL inside-out. It's not because they don't know about MATCH AGAINST - it's because specialized tools win at scale.
I don't doubt you got those results. The thing I was addressing is the example query. If that query needs 3 to 8 seconds there is a problem with the database.
I can see how more complex queries might slow things down substantially.
I'm not going to dispute that. I mention it because you mention in the beginning and at the end using
LIKEas a way to do search with a SQL database. If there are people that are usingLIKEthey don't understand the consequences of a search.The point I was trying to make is that the post takes an uninformed way to doing search, and you used least search prepared database to compare Elasticsearch against.
I think the post has a lot of valuable information. I just wanted to point out the skewed comparison.
Thanks for the feedback, but I think you're missing some important context here.
You're right that LIKE shouldn't be used - that's literally the point of the article
The opening example with LIKE queries isn't presented as "the right way to do MySQL search" - it's explicitly labeled as "What we all start with (and regret)" and "The Nightmare Before Elasticsearch." It's a cautionary tale, not a recommendation.
The comparison isn't actually skewed
You say I'm comparing against "the least search prepared database," but:
The performance table includes MySQL full-text search - it shows 2,100ms vs Elasticsearch's 47ms. That's a proper apples-to-apples comparison, and Elasticsearch is still 44x faster.
The article explicitly mentions MySQL full-text - I literally write: "You add indexes. It helps... a little. Still 3-4 seconds for complex searches."
Real-world complexity matters - The benchmarks aren't just simple searches. They include:
Multiple filters (brand, price range, rating)
Sorting by relevance
Typo tolerance
500k records with realistic query patterns
Where your criticism doesn't hold up:
"If that query needs 3 to 8 seconds there is a problem with the database"
This statement ignores reality. Even with proper full-text indexes, MySQL struggles with:
Multi-field searches with different weights
Real-time typo correction
Complex relevance scoring
Faceted search with aggregations
Concurrent search load at scale
I've run these exact tests on properly configured MySQL 8.0 with full-text indexes, InnoDB optimizations, and query caching. The 2,100ms average for complex searches is accurate.
The article's audience context
You're assuming the audience already knows about MATCH AGAINST and proper MySQL full-text configuration. But many Laravel developers don't - and that's okay! The article meets them where they are, shows them why their current approach fails, and guides them toward a solution.
If someone is already using MySQL full-text search properly and it's working fine, they're not the target audience for this article. This is for teams hitting real performance walls.
What would make your feedback more accurate:
Instead of calling the comparison "skewed," you could say: "The article could be clearer that MySQL full-text search (not LIKE) is the proper baseline for comparison, and you should try that before jumping to Elasticsearch."
I read the point of the post as going from
LIKEto Elasticsearch. Because that are the two things that are being repeated.With the least search prepared database statement I was thinking about Postgres with the search specific indexes and a ranking feature. Not every SQL database is build the same. So instead of going from one database type to another with a different query language, it is possible to just change to a different SQL solution.
Postgres can handle more than Mysql when it comes to search.
You are hammering on the benchmark, but you are not showing the code or the database configurations. As long as the benchmarks can't be peer reviewed the result is debatable.
But In this case I have no doubt Elasticsearch it the fastest one, it is purpose build.
The comparison is skewed to favor Elasticsearch over any other solution, comparing it with
LIKEstatements is just one of the ways it is skewed. Don't put words in other peoples mouths.David, I appreciate the feedback, but I think you're misinterpreting the article's intent. "Comparison is skewed"The article isn't claiming to be an exhaustive comparison of all search technologies. The title explicitly states: "Your Laravel Search Takes 8 Seconds? Here's How I Cut It to 47ms"This is a practical case study, not an academic benchmark paper. The scenario is specific:
Laravel application
500k+ records
Currently using LIKE queries (which many Laravel apps do)
Need for typo tolerance and relevance scoring
The comparison with LIKE isn't "skewed" - it's the actual problem statement. That's what the target audience is experiencing.Re: "Don't put words in other peoples mouths"I'm not putting words in your mouth. You wrote: "with the least search prepared database statement"I interpreted that as referring to LIKE queries (which is what the article discusses). If you meant PostgreSQL full-text search instead, that's a different topic - and yes, I could have mentioned it as an intermediate solution.
I think we are on the same page. Thank you that you wanted to continue the discussion.