This is the most common cause of Shopware search being slow. Every time you import products, update prices in bulk, or run a migration, the Shopware Elasticsearch index needs to rebuild. If it does not rebuild, the index becomes stale. Shopware detects this and falls back to MySQL queries. Your search still works, but it runs on the database instead of Elasticsearch — and it is far slower.

The Shopware Elasticsearch index also becomes stale after server restarts, failed deployments, or interrupted cron jobs. Many stores run for weeks with a stale index and the store owner has no idea because search still returns results — just slowly.

How to confirm: Run this command on your server and check the output.

• ✦Rebuild the Shopware Elasticsearch index fully usingphp bin/console es:index. This command reindexes all products, categories, and custom entities. On large catalogues, this may take 10 to 30 minutes — run it during off-peak hours.
• ✦After reindexing, runphp bin/console es:index:cleanupto remove old index aliases. Old index aliases can conflict with new ones and cause query routing errors.
• ✦Set up a scheduled task to rebuild the Shopware Elasticsearch index automatically after every product import. Add this as a Shopware scheduled task or a cron job that runs the reindex command.
• ✦Check your Shopware deployment pipeline. If your deployment runscache:clearwithout also runninges:index, the index becomes stale on every deploy. Add the reindex step to your pipeline.

Elasticsearch runs inside a Java Virtual Machine and needs enough heap memory to hold active index segments and query caches in RAM. When the heap is too small, the JVM runs garbage collection pauses. During these pauses, all query threads are blocked. The result is search latency spikes — sometimes lasting two to five seconds.

Shopware Elasticsearch performance degrades sharply when heap is set below 1GB. The default Elasticsearch install often sets heap to 256MB or 512MB. For a Shopware store with 10,000 or more products, this is far too low. The correct value is half of the physical RAM available on the server, capped at 31GB.

How to confirm: Check the current heap settings and JVM stats.

• ✦Edit the Elasticsearch JVM options file at/etc/elasticsearch/jvm.options. Set-Xmsand-Xmxto the same value — half of your total server RAM. For a server with 8GB RAM, set both to4g.
• ✦Never set Elasticsearch heap above 31GB. Above this threshold, the JVM switches from compressed object pointers to full 64-bit pointers. This increases memory use and makes GC pauses worse, not better.
• ✦Restart Elasticsearch after changing heap settings:systemctl restart elasticsearch. Then monitor the heap usage again to confirm it stays below 75% under normal search load.
• ✦Check that the remaining server RAM (after Elasticsearch heap) is enough for Shopware PHP-FPM, MySQL, and the operating system. A balanced split for a 16GB server is typically 6GB for Elasticsearch, 4GB for MySQL, and the rest for PHP and system processes.

Elasticsearch divides each index into shards. Each shard is a self-contained Lucene index. The number of shards affects both search speed and memory use. Too few shards on a large catalogue forces every query to scan the full index on a single thread. Too many shards on a small catalogue wastes memory and adds routing overhead.

Shopware Elasticsearch creates indexes with a default shard count. This default works well for small stores. However, once your catalogue grows past 50,000 products, the default shard count becomes a bottleneck. Shopware search performance degrades not because Elasticsearch is broken, but because the index structure no longer fits the data volume.

• ✦Check your current shard count withcurl -X GET "http://localhost:9200/_cat/indices?v". Look at thepricolumn for primary shards. One primary shard per index is fine for up to about 30 GB of index data.
• ✦For catalogues with more than 50,000 products, use three to five primary shards per index. Set this in your Shopware Elasticsearch configuration before reindexing — shard count cannot change on an existing index.
• ✦Configure shard settings in Shopware via theSHOPWARE_ES_INDEX_PREFIXenvironment variable combined with a custom Elasticsearch index settings file. Your Shopware developer can add a custom index configuration subscriber to apply these settings during reindex.
• ✦Set one replica shard per primary shard for production stores. Replicas allow Elasticsearch to handle read queries in parallel and provide redundancy if a node goes down.

Shopware lets you add custom fields to products, categories, and customers. These fields are stored in the database but they are not indexed in Elasticsearch by default. When a customer searches or filters by a custom attribute — a material type, a certification number, a compatibility code — Shopware Elasticsearch cannot find it. The search either returns no results or falls back to a slow MySQL query.

This is a common cause of Shopware search not working correctly for B2B stores. B2B catalogues often rely heavily on custom fields for part numbers, industry codes, and technical specs. Without explicit Elasticsearch mapping for these fields, product search is unreliable and slow.

• ✦Create a custom Elasticsearch definition class for your Shopware store. This class extendsAbstractElasticsearchDefinitionand maps your custom fields to the Elasticsearch index with the correct field types —keywordfor exact matches,textfor full-text search,floatfor numeric ranges.
• ✦Register the custom definition as a Symfony service in your Shopware plugin’sservices.xml. Tag it withshopware.es.definitionso Shopware includes it during the next reindex.
• ✦After adding the mapping, rebuild the full Shopware Elasticsearch index to apply the new field structure. Custom field mappings do not take effect on existing index data — a full reindex is always needed.
• ✦For product variants, confirm that all variant-level attributes (size, colour, material) are mapped at the variant level in the index. Shopware Elasticsearch indexes variants as nested objects — a missing nested mapping causes filter queries on variants to return no results.

Shopware Elasticsearch can be enabled in the admin but still not work if the service is not running or if the host and port in the configuration do not match where Elasticsearch is actually listening. In this state, Shopware silently falls back to MySQL search on every query. The store appears to work normally, but every search is slow.

This happens most often after server migrations, hosting changes, or Docker container restarts. The Elasticsearch service starts on a different internal IP or port, but Shopware’s .env file still points to the old address. Shopware search is not working because it cannot reach Elasticsearch at all — even though the service itself is healthy.

• ✦Check that Elasticsearch is running withsystemctl status elasticsearchordocker psif you use Docker. Confirm the service is active and has been running without restarts.
• ✦Verify the host and port in your Shopware.envfile match where Elasticsearch is listening. The relevant variables areSHOPWARE_ES_HOSTSandSHOPWARE_ES_ENABLED=1. Test the connection withcurl http://<your-es-host>:9200.
• ✦Check your server firewall rules. In many setups, Elasticsearch listens onlocalhost:9200and is blocked on external interfaces. If Shopware runs on a separate server from Elasticsearch, the firewall must allow internal traffic on port 9200 between the two hosts.
• ✦Set up a monitoring alert for the Elasticsearch service. Use a simple uptime check or integrate with your server monitoring tool to send an alert when Elasticsearch stops responding. This prevents the silent fallback from running undetected for days or weeks.