The best lightweight Elasticsearch-compatible search servers in 2026

TL;DR — "Elasticsearch-compatible" means a different slice of the API for each server. OpenSearch keeps the whole API and the cluster. ZincSearch and XERJ are small single nodes. Quickwit and OpenObserve are built for logs on object storage. Manticore is SQL-first with Elasticsearch-compatible writes.

Pick one in ten seconds

• Pick OpenSearch if your clients use much of the Elasticsearch API and you need a cluster. It is the heaviest option here, and the most complete.
• Pick ZincSearch if you ingest through the Elasticsearch bulk API and want one small binary with its own UI, for up to hundreds of GBs.
• Pick Quickwit if you search logs or traces and want the data kept on S3 or other object storage.
• Pick OpenObserve if you want logs, metrics and traces with dashboards in one AGPL server.
• Pick Manticore Search if your team prefers SQL and a MySQL client.
• Pick Elasticsearch itself if you need Elastic's own features and licences are not a problem.
• Pick XERJ if one node is enough and your client needs search, aggregations and kNN through the Elasticsearch REST API, plus an MCP server for agents.

Summary table

OpenSearch: the full API, the full weight

OpenSearch is Apache-2.0 and includes Apache-licensed Elasticsearch code, so it keeps an Elasticsearch-style REST API. It clusters, and it has its own dashboards.

It is not lightweight. It runs on the JVM like Elasticsearch, and for local use you start it with Docker in single-node mode.

ZincSearch: one binary for app search

ZincSearch is a single binary that accepts the Elasticsearch ingest APIs, single record and bulk, and ships its own search UI. Its README says Kibana is not supported, high availability is not available, and the maximum data supported is hundreds of GBs.

Within those limits it is the simplest server here to start.

Quickwit and OpenObserve: logs on object storage

Quickwit keeps its data on object storage such as Amazon S3 and exposes a documented subset of the Elasticsearch API, enough for common log shippers. Without a Kafka source, Quickwit indexing has no high availability; search does.

OpenObserve is an AGPL-3.0 platform for logs, metrics and traces, with Parquet columnar storage on S3-compatible storage. Both publish cost and speed comparisons against Elasticsearch; we did not verify them.

Manticore Search: SQL first

Manticore treats SQL as its native language and speaks the MySQL protocol, with an HTTP JSON API and Elasticsearch-compatible writes on top. If your team thinks in SQL, it may suit you better than any Elasticsearch look-alike.

XERJ: a conformance-tested single node

XERJ speaks the Elasticsearch REST API from one binary, and its conformance suite passes 1366 of 1369 cases on every commit. One published board measured it against a live Elasticsearch 8.13.4 on one host at 100,000 documents: 55 wins, 26 ties, 4 losses and 3 not-applicable. All 4 losses were read p99 under a write flood (XERJ vs Elasticsearch).

What it gives up: it is single-node only, it is a release candidate, and indexing can use a lot of memory. Our JSONL benchmark recorded a 9.1 GiB peak on one 9.7 MB file.

When to choose Elasticsearch instead

Choose Elasticsearch when you need Elastic's own features, Kibana, or a vendor support contract, and its licences suit you. Every server above covers only part of what it does, and the board above measured XERJ against 8.13.4 on one host, not against a cluster.

How this page was checked

Licences, install lines and capabilities were read from each project's README or LICENSE file on 2026-10-19. Stars and latest releases came from the GitHub REST API the same day. No cross-vendor benchmark was run for this page; the XERJ numbers come from the repository's README and its published scorecard.

FAQ

Which Elasticsearch alternative is a drop-in replacement?

OpenSearch is the closest, because it includes Apache-licensed Elasticsearch code and keeps clustering. The lighter servers each cover a slice: ZincSearch covers ingest with its own search UI, Quickwit a documented subset aimed at logs, Manticore writes, and XERJ a conformance-tested single node.

Which one runs as a single binary?

ZincSearch, OpenObserve and XERJ each describe themselves as a single binary. OpenSearch and Elasticsearch run on the JVM and are usually started with Docker for local use.

Which one scales past one machine?

OpenSearch, Elasticsearch, Quickwit, OpenObserve and Manticore support multi-node setups. ZincSearch's README lists high availability as not available, and XERJ is single-node only.

Can I keep using Kibana?

Kibana is Elastic's own UI. ZincSearch says Kibana is not supported and ships its own UI; OpenSearch has OpenSearch Dashboards; OpenObserve and Quickwit ship their own UIs. Check your exact Kibana version against any alternative before switching.

How does XERJ compare with Elasticsearch on the same host?

One published board measured both on one host at 100,000 documents: 55 wins, 26 ties, 4 losses and 3 not-applicable across 88 cells against Elasticsearch 8.13.4. All 4 losses are read p99 under a write flood. XERJ is single-node only.

Were the vendors' speed claims verified?

No. Manticore, Quickwit and OpenObserve publish their own speed and cost comparisons against Elasticsearch. This page quotes none of them as fact and ran no cross-vendor benchmark.

Evidence

• OpenSearch is Apache-2.0, includes Apache-licensed Elasticsearch code, and runs as a single node with docker run and discovery.type=single-node. — https://github.com/opensearch-project/OpenSearch
• ZincSearch is a single binary, is compatible with the Elasticsearch APIs for ingestion (single record and bulk), does not support Kibana, has no high availability, and its README lists hundreds of GBs as the maximum data supported. — https://github.com/zincsearch/zincsearch
• Quickwit exposes an Elasticsearch-compatible API subset, searches indexes on object storage such as Amazon S3, and offers high availability for search, and for indexing only with a Kafka source. — https://github.com/quickwit-oss/quickwit
• Manticore Search is SQL-first and MySQL-compatible, offers an HTTP JSON API with Elasticsearch-compatible writes, and is distributed under GPLv3 or later. — https://github.com/manticoresoftware/manticoresearch
• OpenObserve is an AGPL-3.0 observability platform for logs, metrics and traces with Parquet columnar storage on S3-compatible object storage. — https://github.com/openobserve/openobserve
• Elasticsearch's default licence is a choice of AGPL-3.0, SSPL v1 or Elastic License 2.0, and start-local runs it with Kibana in Docker for local development. — https://github.com/elastic/elasticsearch
• XERJ's conformance suite runs on every commit and passes 1366 of 1369 cases. — README.md
• The published board against a live Elasticsearch 8.13.4 at 100,000 documents on one host is 55 wins, 26 ties, 4 losses and 3 not-applicable across 88 cells. — demo/playbooks/SCORECARD.md
• In the JSONL benchmark of 2026-10-19 the XERJ node peaked at 9,578,548 kB (about 9.1 GiB) resident while indexing one 9.7 MB file of 50,000 records. — benchmarks/best-of-jsonl-search-2026/README.md

Related

• Is there an Elasticsearch-compatible engine that isn't Elasticsearch?
• What's a local alternative to Meilisearch that indexes a folder by itself?
• Do I need Typesense for an agent to search my docs?
• The best local full-text search for JSONL and CSV files in 2026, with a published benchmark
• Does XERJ support S3 storage, alerting or custom plugins yet? · same intent: search engine alternatives
• Is there a single-binary local search engine I can just run? · same intent: search engine alternatives