AsterSearch vs Elasticsearch

ES depth. None of the ops tax.

Elasticsearch is powerful — and a part-time job. AsterSearch gives you the parts that matter (BM25, vectors, aggregations, ILM, log search) on a single Rust binary, with multi-tenancy and Stripe metering already wired. No JVM tuning. No shard math. No 3 a.m. cluster pages.

Honest scope

Where we are — and aren't — trying to win.

We don't claim feature-by-feature parity with a 14-year-old product. We claim parity on the workloads that actually keep teams on ES — and we're explicit about the rest.

Capability Elasticsearch AsterSearch
BM25 full-text searchTantivy 0.22
Vector search (HNSW)Lucene 9.xUSearch + int8/int4 quantization
Hybrid retrieval (BM25 + vector + RRF)Manual RRFBuilt-in, single query
Aggregations (date_histogram, range, stats, cardinality, percentiles)Q4 ship — five core aggs
Index Lifecycle Management (rollover, freeze, delete)Q4 — hot/warm/cold tiers
Function score (decay, filter_weight, modifiers)Full composition matrix
Kibana-compatible _search DSL subsetQ4 — Grafana datasource works
OTLP-native log ingestOTel collector glueNative via log-search-cell
Cross-cluster searchPost-v1 (Q1 2027)
Painless / scripted scoringDeliberately omitted
ML data frames / anomaly detectionPost-v1
Parent / childNested only
Self-hostableHeavy opsSingle binary
BYOC (Helm into your VPC)Elastic Cloud onlyQ4 ship — control plane stays SaaS
Cost story

Why "ES is overkill" is a real budget line.

For application-search and log-search workloads under ~10TB, ES forces you to pay for features you don't use and capacity you don't need.

No JVM

Rust binary, predictable RSS. No "increase your heap" runbook, no GC pauses, no 50% memory overhead.

Auto-tiering

NVMe hot · HDD warm · S3 cold, driven by age and access. Synthetic-workload cost drops ≥ 30% vs hot-only.

Native multi-tenancy

Tenants share infra without index-per-tenant explosion. ES forces a cluster-per-noisy-neighbor.

Migration path

Algolia → AsterSearch in a day. ES logs → AsterSearch in a week.

We have a playbook for both. The ES log migration uses OTLP ingest at the collector level, an ILM policy that mirrors yours, and the Kibana DSL subset so existing Grafana dashboards keep rendering.

If your ES cluster is overkill — try the search-shaped tool.

Start free