Elasticsearch Is Built for Log Analytics, Not Site Search

Why Elasticsearch is overkill for site search

Elasticsearch was created at a time when organizations needed to search and analyze massive volumes of unstructured data: server logs, application metrics, security events, and clickstream data. It solves that problem exceptionally well. The Elastic Stack (Elasticsearch, Kibana, Logstash, Beats) is the backbone of observability infrastructure at thousands of companies.

But running Elasticsearch for website search introduces a level of complexity that is disproportionate to the problem. Here is what operating Elasticsearch actually involves:

• JVM heap tuning. Elasticsearch runs on the JVM. You need to configure heap size (typically 50% of available RAM, capped at 32GB), monitor garbage collection pauses, and tune JVM flags to avoid out-of-memory kills. For a site search index with a few thousand pages, this is unnecessary overhead.
• Shard and replica management. Data in Elasticsearch is split into shards distributed across nodes. You need to decide how many primary shards to create (this cannot be changed after index creation without reindexing), how many replicas to maintain, and how to handle shard allocation when nodes go down.
• Cluster scaling. As your data or query volume grows, you add nodes to the cluster. This means provisioning new servers, configuring discovery settings, waiting for shard rebalancing, and monitoring cluster health (green, yellow, red). A single-node cluster is a single point of failure.
• Rolling upgrades. Upgrading Elasticsearch requires taking nodes offline one at a time, waiting for shard reallocation, upgrading the software, and bringing nodes back. Major version upgrades often require reindexing all data. Skipping versions is not supported.
• Security configuration. Elasticsearch does not enable security by default in all configurations. You need to configure TLS, set up user authentication, manage role-based access, and ensure your cluster is not exposed to the public internet (a common source of data breaches).
• Monitoring and alerting. A healthy Elasticsearch deployment requires monitoring cluster state, node disk usage, JVM memory pressure, search and indexing latency, thread pool rejections, and circuit breaker trips. This typically means running Kibana or a third-party monitoring stack alongside Elasticsearch itself.

None of this is necessary if you just need users to search your documentation, product catalog, or blog. That is the problem Sprigr solves: purpose-built site search with zero infrastructure.

Migrating from Elasticsearch to Sprigr

If you are currently using Elasticsearch for site search, migrating to Sprigr simplifies your stack considerably. The process involves exporting your documents from Elasticsearch and pushing them to the Sprigr REST API.

Elasticsearch stores documents as JSON objects, and Sprigr indexes JSON objects with the same structure. Export your documents from Elasticsearch (using the Scroll API or a simple query), map them to Sprigr's record format (each record needs an objectID and your searchable attributes), and push them via the Sprigr REST API. The API is Algolia-compatible, so if you have experience with Algolia's record format, the structure will be familiar.

On the frontend, you replace your Elasticsearch query logic (whether you were using the JavaScript client, a REST proxy, or a custom backend) with Sprigr's single script tag. The search module loads your index and handles queries locally in the browser. You can remove your Elasticsearch cluster, your search proxy server, and any associated monitoring infrastructure.

For teams that built custom relevance tuning in Elasticsearch (boosting, function scores, decay functions), Sprigr provides searchable attribute priority ordering, custom ranking attributes, and hybrid semantic search with reciprocal rank fusion. The tuning model is simpler but covers the common site search scenarios without writing complex query DSL.