Why PrestaShop Checkout Slows Down When You Add an External Search Engine

A side effect you do not expect

People install Elasticsearch, OpenSearch or Meilisearch on PrestaShop almost always for one reason: native search cannot keep up with a large catalog. And search does get better. What sometimes goes unchecked is what happens to the rest of the shop, in particular the cart and checkout, when that external index has to stay in sync with stock and availability, which change on every single sale.

The reason this part gets overlooked is simple: in a demo, with a handful of orders, nothing shows up. The problem appears under real load, when several orders come in at the same time, and by then the customer is already paying. That is not where you want to discover a bottleneck.

What has to happen when a customer changes a cart quantity

With an external search engine, every product lives twice: a row in PrestaShop's database, and a "document" inside the search engine's index, holding the fields needed to find and filter it (name, price, categories, availability, and more). When a customer adds a product to the cart, changes a quantity, or an order is confirmed, that product's availability changes, and the document in the search index has to reflect it, otherwise another shopper could see a just-sold-out product as available.

The simplest way to do this, and also the most expensive, is to rebuild the whole document from scratch every time: reread name, description, price, categories, images and everything else from the database, in order to update three numbers (quantity, availability, an availability-based sort order). If this rebuild fires once per order line, an order with five different products triggers it five times, at the exact moment the customer is waiting for payment confirmation.

The real numbers

Measured on PrestaShop 9.0.0, with two shops connected to Elasticsearch, a five-line order that rebuilt the full document for every line cost 243 database queries and 229 milliseconds, just to move three numbers into the search index. That is not the time for the whole checkout, it is the time for one step inside it, the one that keeps the index in sync.

With a dedicated path that updates only the fields that actually changed (quantity, availability, availability-based order) instead of rebuilding the whole document, the same order on the same shops dropped to 9 queries and 16 to 47 milliseconds. Same operation, same end result in the index, only the amount of work needed to get there changes.

The technical difference is easy to explain even to someone who does not write code: an external search engine normally offers two ways to update a document. The first is "replace it entirely", useful when something structural actually changes, like the name or the price. The second is "update just these fields", built for the far more common case where only availability changes. Always using the first way, even when only the second is needed, is the most common cause of a checkout that slows down exactly when the shop is selling more.

Why it almost always happens in the same spot

In PrestaShop, the event that signals a quantity change during an order can fire once per order line, not once per whole order. It is easy to write the code that listens to this event thinking "it's just one update", without noticing that on an order with many lines, or during a sales spike with many concurrent orders, that single choice multiplies by the number of lines and by the number of orders happening at the same time. A search module that looks fast in tests with one order at a time can behave very differently during a Black Friday with hundreds of simultaneous checkouts.

What to ask if you already have an external engine

• Ask your search module or your integrator whether a cart quantity change updates only the stock fields, or rebuilds the entire product document.
• Run a test with a multi-line order during a quiet moment and watch the database slow query log during checkout: if you see dozens of repeated queries for the same product, this is exactly the symptom.
• If you run a B2B or wholesale shop with many-line carts, this problem scales badly: a thirty-line cart with a full rebuild per line is six times slower than a five-line one, while with a targeted update the difference is far smaller.
• This is not a reason to avoid an external search engine, a large catalog still needs one for search. It is a reason to check how the integration between the cart and the index was actually written.

The short version

An external search engine does not slow down checkout by itself. What slows down checkout is an integration that rebuilds the entire search document for a change that only concerns three numbers. The measured difference, from 243 queries and 229 milliseconds to 9 queries and 16 to 47 milliseconds on the same order, is the kind of work we did inside cll_essearch by separating stock updates from structural updates on Elasticsearch, OpenSearch and Meilisearch. If your shop uses an external engine and checkout gets slower exactly when sales pick up, this is the first thing to check.

Elasticsearch Search & Faceted NavigationLightning-fast, typo-tolerant search and modern modal faceted navigation with the built-in engine, or powered…€99.99View product