ElasticPress vs MySQL FULLTEXT: Which WordPress Search to Use

WordPress search is bad out of the box: it runs LIKE '%term%' against wp_posts, which cannot use an index and ranks nothing. The two real ways to fix it are MySQL FULLTEXT, a search index inside the database you already run, and ElasticPress, which routes search to a dedicated Elasticsearch engine. They sit at opposite ends of a tradeoff: FULLTEXT adds no infrastructure but is a basic matcher, ElasticPress is a genuine search engine but is another service to run. Here is the honest comparison and which one fits which site.

The short answer

If your site is modest (well under roughly 10,000 posts or products), search is mostly "find the page with this word," and you do not need faceted filtering, MySQL FULLTEXT is enough and the right call: no extra infrastructure, nothing else to host. If your catalog is large, search relevance directly affects revenue, or you need faceted filtering and typo tolerance, ElasticPress with Elasticsearch wins and the operational cost is worth paying. Most small blogs and small stores should not run Elasticsearch. Most large WooCommerce catalogs should.

What each one actually is

MySQL FULLTEXT is a FULLTEXT index type on InnoDB tables, queried with MATCH() ... AGAINST(). It tokenizes text into words and can rank results by a basic relevance score. WordPress core does not use it for search by default, so you either add it through a plugin or with custom code that swaps the LIKE query for a MATCH ... AGAINST query.

SELECT ID, MATCH(post_title, post_content) AGAINST('wireless headphones' IN NATURAL LANGUAGE MODE) AS score
FROM wp_posts
WHERE MATCH(post_title, post_content) AGAINST('wireless headphones' IN NATURAL LANGUAGE MODE)
  AND post_status = 'publish'
ORDER BY score DESC;

ElasticPress is a WordPress plugin from 10up that indexes your content into Elasticsearch and transparently routes WP_Query search to that engine. Elasticsearch stores data in an inverted index and applies analyzers, stemming, relevance scoring, and aggregations. Setup and the ep_integrate flag are covered in How to Use ElasticPress with WP_Query.

Feature comparison

Where MySQL FULLTEXT is genuinely enough

For a blog, a small content site, or a store with a few thousand products, FULLTEXT does the job. It searches titles and content, ranks results well enough that the right page is usually near the top, and adds nothing to your stack. It is in the database you already run, back up, and monitor. There is no second service to keep alive, no index to resync, no extra bill. For a large share of WordPress sites, that is the correct engineering decision: the simplest thing that works.

It also has a real ceiling. FULLTEXT ignores tokens shorter than innodb_ft_min_token_size (3 by default for InnoDB, and changing it means rebuilding the FULLTEXT indexes), has a stopword list that drops common words, does not handle typos, and its relevance model is shallow. You cannot weight a title match above a body match without extra work, and faceted filtering still falls back to wp_postmeta JOINs because FULLTEXT indexes text columns, not arbitrary product attributes.

Where MySQL FULLTEXT breaks

The wheels come off in three situations. Scale: as the catalog grows into the tens of thousands of rows, search slows down and there is no clean horizontal fix. Faceted filtering: "in-stock blue medium shirts under 40 dollars" is not a text search, it is a multi-attribute query, and on wp_postmeta that becomes a deep JOIN stack that FULLTEXT does not help with. Relevance that matters: on a store, a shopper who searches "headphones" and does not see the best-matching products in the first few results leaves. FULLTEXT's ranking is not tuned for that, and it cannot do typo tolerance, so "headphnes" returns nothing.

What ElasticPress adds, and what it costs

Elasticsearch is built for exactly the cases where FULLTEXT breaks. The inverted index keeps text search fast as data grows. BM25 scoring plus per-field weighting means a title hit outranks a passing mention. Fuzziness for typo tolerance is available, though ElasticPress's default search algorithm leaves it off, because loose matching tends to cost more relevance than it recovers. Aggregations make faceted counts cheap. ElasticPress wires all of that into WP_Query so your theme code barely changes.

The cost is real and worth stating plainly. Elasticsearch is a separate service: you host it (self-managed, or via a managed Elasticsearch provider), monitor it, and keep its index in sync with WordPress. Indexes need rebuilding after mapping changes and can drift out of sync after bulk imports. That is ongoing operational work a pure-MySQL site does not have. ElasticPress is worth it when search quality or scale is a business problem, and pure overhead when it is not.

The verdict by site size

• Small blog or content site: MySQL FULLTEXT. Elasticsearch is overkill.
• Small store, simple search, a few thousand products: MySQL FULLTEXT, or a plugin like Relevanssi or SearchWP that maintains its own index inside the database.
• Large catalog, faceted filtering, search-driven revenue: ElasticPress with Elasticsearch. The operational cost pays for itself.
• Growing store not sure yet: start on FULLTEXT, watch search and filtered-category latency, and move when the numbers say so. Do I Need ElasticPress? is the checklist for that decision, and How to Optimize WooCommerce puts search in the context of the other performance layers.

Search is one layer of store performance, not the whole picture. If you do adopt ElasticPress, Elasticsearch vs OpenSearch for ElasticPress explains why it officially targets Elasticsearch and where OpenSearch actually stands.

FAQ