From Elasticsearch

When to migrate and what changes.

Elasticsearch and Skryx solve overlapping problems with different trade-offs. Elasticsearch is a general-purpose search and analytics engine you operate yourself; Skryx is a hosted search SaaS with strong defaults for product / content search.

# When Skryx wins

  • You're tired of capacity-planning Elasticsearch nodes.
  • You want typo tolerance, synonyms, ranking and AI features included, not configured.
  • You want sub-50 ms response on commodity payloads without tuning shards / replicas.
  • You don't need Elasticsearch's analytics-engine features (aggregations across billions of docs, parent-child, geo-shape queries, etc.).

# When Elasticsearch is the right answer

  • You're already running it well and your team owns the cluster.
  • You need log/metrics analytics — that's Kibana territory.
  • You need Painless scripting at query time for arbitrary scoring.

# Mapping the concepts

Elasticsearch Skryx
Cluster (managed by Skryx)
Index Index
Mapping Schema
Document _id id
_source document
match / multi_match q + query_by
bool.filter filter_by
aggs (terms) facet_by
function_score Ranking rules
Analyzers + filters typo_config, stop_words, synonyms

# Migration path

  1. Export each ES index to JSON. elasticdump or a custom scroll script.
  2. Provision the Skryx index with the create-index endpoint.
  3. Use batch upsert to load. 1,000 docs per request, parallelised.
  4. Translate one representative query at a time — start with your top three.
esc