Performance Boost for Search: OpenSearch and Typesense in Cluster Operation

In modern e-commerce, the search function is much more than just an input field. It is the most important salesperson in the shop. Users who use the search have a clear purchase intention - but this intention quickly fades if the results take seconds to appear or are irrelevant.

Many agencies either use the standard database search (which quickly buckles under large catalogs) or external SaaS search solutions. However, the latter often incur high monthly costs, additional latencies due to external API calls, and data protection issues. The solution: High-performance search engines like OpenSearch or Typesense, which are operated as an integral part directly in the Kubernetes cluster.

1. Why the Database Alone Isn’t Enough

Standard databases like MariaDB are optimized for structured data but not for “Fuzzy Search” (fault tolerance), stemming analysis, or complex filtering across thousands of variants.

• Load Separation: Running a complex search directly on the main database diverts computing power from the checkout process.
• Relevance: Specialized search engines offer ranking algorithms that weight results by relevance rather than just by the occurrence of a term.

2. OpenSearch vs. Typesense: The Right Choice for the Workload

On a modern e-commerce platform, we use different tools depending on the requirements:

• OpenSearch: The industry standard for maximum flexibility. OpenSearch (the open-source fork of Elasticsearch) is extremely powerful with huge data volumes and complex aggregations. Within the cluster, we operate OpenSearch as a scaled federation that parallelizes indexing and search.
• Typesense: The “Fast-Track” alternative. Typesense is an in-memory search engine designed for extreme speed and easy configuration. It is ideal for “search-as-you-type” experiences, where results appear in milliseconds while typing.

3. Optimizing Indexing in the Cluster

A common problem with large catalogs is indexing: When thousands of products are updated, it must not slow down live search. Through orchestration in the Kubernetes cluster, we solve this elegantly:

• Asynchronous Updates: Product changes are transferred to the search engine in the background via message queues (like RabbitMQ). The shop visitor notices nothing of this process.
• Sidecar Architecture: Search services run in close proximity to the shop pods. Communication takes place over the internal, high-performance cluster network. This eliminates the latencies that would occur with external SaaS solutions over the public internet.

Conclusion: Speed as a Conversion Lever

By integrating OpenSearch or Typesense directly into their own platform, agencies regain full control over the search experience. The results are faster, filtering is more precise, and costs remain stable - no matter how often the index is updated. For the end customer, this means a smooth shopping experience that significantly increases the likelihood of a purchase.

FAQ

Why is a search in your own cluster better than an external SaaS solution? Two main reasons: speed and cost. Internal communication in the cluster is many times faster than an API call over the internet. Additionally, the often high transaction fees of SaaS providers are eliminated, as you only pay for the resources used in the cluster.

Is Typesense really faster than OpenSearch? Typesense often has an advantage in pure response time (latency) due to its in-memory architecture and is easier to configure. OpenSearch shows its strengths when very complex logic, large data volumes, or extensive analytics functions are required.

How complex is the maintenance of your own search engine? In a managed Kubernetes setup, we take care of the deployment, monitoring, and updates of the search instances. The agency only needs to handle the configuration of the search logic in Shopware.

Does Shopware natively support these technologies? Yes, Shopware offers excellent integration for Elasticsearch/OpenSearch. For Typesense, there are proven plugins and libraries that enable easy integration.

What happens if the search engine fails? Due to the cluster operation, the search engines are also redundantly designed. If one instance fails, the others take over seamlessly. Additionally, the shop can be configured to temporarily fall back on the database’s basic search in an absolute emergency, so that sales never stop.