What Running Search Across Hundreds of Storefronts Taught Us About the Elasticsearch Fork

We recently came within one hire of putting a full-time engineer on a job that didn’t really need a person at all (and no, this is not an AI-replacement story).On-site search is one of those features that ends up getting treated as solved long before it actually is. It’s in every industry, from healthcare portals to SaaS platforms to internal documentation to media libraries. Anywhere your users or customers or partners need to find something inside a site, product or catalogue, some version of it exists. Call me biased, but in our world—e-commerce—the failure mode can be especially fast and irrevocable. A shopper types a few letters and, in this day and age, expects the right product before they finish the word. When that works, they convert. When it doesn’t, they leave and buy it somewhere else. Often, the store doesn’t know why. It’s a silent exit that’s one of the more expensive problems in online retail. The infrastructure under it has a lot of sway on success, but it needs the right strategy. This was ours. How a lot of teams ended up on legacy Elasticsearch Some quick historical context. Back in January 2021, Elastic changed the license on Elasticsearch and Kibana from Apache 2.0 to the Server Side Public License. SSPL is not an open source license. The Open Source Initiative does not recognize it as one, and for teams running Elasticsearch in production, the effect was essentially a forced reckoning. You could stay the course under the new terms, negotiate a commercial arrangement, or find an alternative. A lot of engineering teams decided to deal with it later, which means a lot of them are still dealing with it now. AWS forked Elasticsearch in April 2021 and released it as OpenSearch under Apache 2.0. OpenSearch is fully open source (full stop). Apache 2.0 permits commercial use, modification, and distribution without restriction. In September 2024, OpenSearch moved under the Linux Foundation, which settled any remaining question about long-term governance. Importantly, this is not a vendor’s project wearing open source clothes (open core, in other words). It’s community-governed infrastructure, and you can run it, fork it, modify it, and never have to renegotiate with anyone. Our situation of inherited infrastructure, forced timeline Our own search infrastructure had arrived through an acquisition, which meant we inherited a hosted Elasticsearch setup and then watched the platform underneath it start to wind down on a timeline we had not chosen and had zero control over. The decision of what to do next effectively got made for us. We could build and run our own OpenSearch cluster (and we know how to do that). But once we worked through the actual cost, the capacity planning, the upgrade cycles, the monitoring, the 2 a.m. pages when a node goes down, etc., it came to close to a full person doing nothing else, which on a small team is not a line you wave through. That is, instead, a person who would stop improving search for the stores paying us to improve their search. We moved Search Magic onto managed OpenSearch through NetApp Instaclustr and kept the surrounding stack straightforward: MySQL for core data, Redis caching for response time, and a layer of APIs and webhooks that manages data flow and triggers reindexing. Reindexing runs through index aliases. We build a new index, map and load the products into it, then swap the alias over once it’s ready, so a live storefront never sees a search index mid-update. A product create, update, or delete queues that store for its own reindex, and with multiple nodes in the OpenSearch cluster, those updates roll through without any visible interruption, even at peak traffic. Search Magic runs across several hundred active storefronts today. Some catalogs reach past a few hundred thousand products, and weekly query volume is in the millions. Query responses stay under a second, and for autocomplete (where shoppers feel latency most acutely!), the bar is faster still. We update indexes for our larger stores as often as every hour to keep product data fresh. What OpenSearch does really well for e-commerce search OpenSearch’s open sourceiness is important beyond the licensing question. OpenSearch gives Search Magic the pieces e-commerce search actually needs. Synonyms and fuzzy matching mean shoppers find products regardless of how they spell or phrase a query. Function_score blends text relevance with business signals like stock status and bestseller rank, so a match isn’t just about text. Post_filter combined with aggregations powers facets that behave the way shoppers already expect from Amazon. The migration off the legacy Elasticsearch setup took under twelve hours and broke nothing, which I had privately braced against given what these projects usually involve. Since then the platform has required close to no day-to-day attention from our team. We only look into OpenSearch these days when our health monitoring flags something down or running slow. From there we check the Instaclustr dashboard to see if the issue traces back to the OpenSearch cluster. Most of the time it doesn’t, and it’s usually the last place we end up looking. What the freed hours actually bought The time we got back comes to roughly two thousand hours a year, around 260 working days, which is approximately what that full-time infrastructure hire would have cost. Those hours went straight back into relevance and ranking work and into per-store tuning that carries over to a merchant’s conversion rate. In short, to optimizing the autocomplete behavior shoppers feel without ever naming it, and nobody on the team opens a laptop to a search outage anymore. If your search infrastructure started life as Elasticsearch, the decision has not gone away. But it has gotten more expensive to defer. OpenSearch has been under active development since the 2021 fork, ships regular releases, and the governance question was settled when it moved under the Linux Foundation. The licensing is clean in a way the current Elasticsearch license is not. You can run it in production and build commercial products on top of it. You can modify it to suit your stack without any of the ambiguity that comes with SSPL. Whether you run it yourself or hand the operations to a managed provider like Instaclustr, it is worth doing the actual math on what your current setup is costing you in engineering time before the next platform sunset makes the decision for you.