What we use Elasticsearch for
We use Elasticsearch where search through the database reaches its limit. That means shops with large ranges and many variants, B2B catalogues filtered across numerous technical attributes, and portals where people search with incomplete terms. In Shopware 6 the connection runs through the search integration provided for it, so that filters, sorting and category pages are all served from the same index.
Then comes the editorial work: synonyms for technical terms and everyday language, weighting of part number, title and description, handling of hyphens and measurements. Elasticsearch is also the basis for semantic search and for the retrieval methods that let language models draw on your own content — RAG. Anyone planning such an application is already halfway there with a well-kept search index.
How we work: index, data, operation
It starts not with the installation but with the mapping: which field is text, which is a filter value, which is a number to sort on. Then data quality. Missing manufacturers, inconsistent units, empty short descriptions — that feeds straight through into the result list. We review the product data before indexing and say what has to be cleaned up first. Index bad data and you get bad results quickly.
In operation it comes down to reindexing after data changes, to memory and heap settings, and to the question of what happens when the service fails. We set up a fallback to the database search so that a shop does not stop just because an index is being rebuilt. The service runs in managed hosting on our own servers in Germany, with monitoring of index status, memory and response times.
When you do not need Elasticsearch
With a few hundred products, Elasticsearch is rarely worth it. The database search in Shopware 6 copes, and the extra service costs memory, maintenance and attention — permanently, not just once at setup. A modest portal with clear navigation often needs a better structure rather than full-text search across everything. Search is no substitute for a category logic nobody designed.
When the search is reported as “bad”, we first check why. Often synonyms are missing, fields are weighted wrongly, or products carry no usable names. That can be fixed in the existing search and costs less than a new service. Only when range, filter depth or result quality demonstrably reach their limit do we talk about Elasticsearch. A well-run search index over unusable data stays unusable.