Infino vs Elasticsearch / OpenSearch
Elasticsearch and OpenSearch are Lucene clusters built around nodes, shards, and data tiers. Infino runs full-text, vector, and SQL over durable Parquet in object storage, with local storage serving as a cache.
diff --stat elasticsearch opensearch infino
The retrieval capabilities overlap. The meaningful difference is the storage and operating model around them.
- Infino keeps one searchable copy in your bucket, with the indexes inside the files. A typical Elasticsearch or OpenSearch production layout keeps primary shards, at least one replica, and snapshots.
- Compute reads the bucket and caches the working set locally, replacing shard sizing and rebalancing with independent compute capacity.
- Durability comes from the object store.
- Infino accepts a supported Query DSL subset. Clients that use compatible bulk, index, and query APIs can be repointed after pipeline-specific behavior is validated.
- Infino provides the query surface and MCP server for building dashboards in an application. Elasticsearch and OpenSearch remain the choice for Kibana, OpenSearch Dashboards, and existing saved-object workflows.
- On the public search-benchmark-game corpus, Infino matches Lucene hit counts; the benchmark reports latency for the same query set.
- Full-text, vector, and SQL share one engine and one copy of the rows.
cat ARCHITECTURE.diff
Where the data lives
For hot search, Elasticsearch and OpenSearch serve Lucene shards from cluster storage. Infino uses object storage as the primary tier.
- Elasticsearch and OpenSearch shard documents across JVM nodes. Searchable snapshots, frozen tiers, and UltraWarm can move colder, read-only data onto object-backed tiers, with a different latency profile.
- Infino puts the bucket in the read path. The engine fetches the slices a query needs and keeps the hot ones in a local cache; object storage is the source of truth, and nothing on the machine is permanent.
- Elasticsearch and OpenSearch use mappings, shard allocation, and cluster scaling. Infino uses a table schema, files in a bucket, and independently sized query compute.
infino bench --full-text
Measured full-text latency
These are Infino measurements at 10M documents. Warm is steady state; cold is the first query against an idle table.
- Warm cache
- Cold cache
Separate cross-engine benchmark (Lucene is the engine behind Elastic/OpenSearch): search-benchmark-game →
infino cost --compare elasticsearch
How the storage model changes the bill
Count the copies of a gigabyte, and where each one sits.
- A typical production layout with one replica and snapshots keeps three copies: primary shards on hot nodes, replica shards in another zone, and snapshots in a bucket. Replica counts and snapshot policy vary.
- Infino keeps one, in your bucket, and it is the searchable one. The columns and the retrieval indexes sit in the same Parquet files.
Elastic Cloud Hosted · Platinum
OpenSearch Service
Infino Cloud Pricing. methodology →
cat RUNBOOK.diff
Operational differences
The operational model changes from stateful shards to compute over durable files in object storage.
| task | elasticsearch / opensearch | infino |
|---|---|---|
| mappings | index templates, dynamic mapping; field proliferation can explode the mapping | the table schema; a new field is a new column |
| cluster | masters, node roles, shard allocation, heap, circuit breakers | compute capacity over durable files in the bucket |
| scaling | size the cluster for the hottest hour; growing means adding nodes and rebalancing shards | storage grows in the bucket; compute is added when queries need it |
| durability | replica shards you provision, place across zones, and pay for | the object store’s durability |
| node loss | shard recovery and rebalancing while the cluster is degraded | the data was never on the node; a new process reads the same bucket |
| retention | hot data stays on cluster storage; colder data can move to searchable snapshots or UltraWarm | object storage is the primary searchable tier; hot byte ranges are cached locally |
| backups | snapshot repositories and lifecycle policies to manage | manifests expose immutable snapshots in place |
| upgrades | rolling restarts across stateful nodes, version-locked shards | upgrade compute separately; durable files stay in the bucket |
infino diff --features
Search and platform capabilities
On search itself the three are close. They split on SQL, the file format, how dashboards get built, and the license.
| capability | elasticsearch | opensearch | infino |
|---|---|---|---|
| keyword search | BM25 | BM25 | BM25 |
| stop words · distance · proximity | native Lucene | native Lucene | unsupported |
| vector search | kNN, HNSW | k-NN plugin, HNSW | HNSW when pinned in RAM; OPANN + Sq16 on object storage |
| hybrid ranking | RRF across sub-queries | search pipelines + normalization | RRF in one query, one pass |
| sql | ES|QL and a SQL plugin | SQL plugin / PPL | DataFusion; search as table functions |
| query DSL | native | native | supported subset |
| ingest clients | Logstash, Beats, Vector; ingest pipelines and ILM | Logstash, Beats, Vector; ingest pipelines and ISM | clients using supported bulk / index APIs can be repointed; validate pipeline-specific features |
| dashboards | Kibana | OpenSearch Dashboards | MCP server + application UI |
| data format | Lucene segments | Lucene segments | standard Parquet |
| where data lives | hot tiers on cluster storage; searchable snapshots for cold data | hot tiers on cluster storage; UltraWarm / cold tiers available | object storage is the primary searchable tier |
| license | AGPLv3 / SSPL / Elastic License 2.0 | Apache-2.0 | Apache-2.0 core engine |
elasticsearch / opensearch · qdrant / pinecone · postgres / clickhouse · snowflake / databricks · iceberg / hudi
cat TRADEOFFS.md
Kibana and Lucene-specific features
Elasticsearch and OpenSearch retain a broader Lucene and dashboard surface.
- Infino dashboards are built through the MCP server and an application UI. Kibana saved objects, Lens, and OpenSearch Dashboards remain on their existing platforms.
- Logstash, Filebeat, Vector, and other tools that speak the API keep working.
- Some Lucene features, including analyzers, span queries, stop words, distance, and proximity, are unsupported.
infino migrate --from elasticsearch
How migration works
Migration reingests source documents into Infino tables because Lucene segments use a different storage format.
- Export with the scroll API or the pipeline you already run.
- Append into Infino tables over REST, Arrow or JSON. Indexing happens on write.
- Compatible queries keep their shape through the supported Query DSL subset. Queries can also be written as REST or SQL: match becomes bm25_search, kNN becomes vector_search, and RRF becomes hybrid_search.
- Run both against real traffic, compare, then move reads.
cat FAQ.md
What is the main difference between Infino and Elasticsearch or OpenSearch?
The default storage and operating model. Elasticsearch and OpenSearch serve hot data from a node-and-shard cluster; both also offer object-backed tiers for colder, read-only data. Infino uses object storage as the primary searchable tier. Its Parquet files contain the columns and retrieval indexes, while local RAM and NVMe are caches, so storage and compute scale separately.
Will existing Elasticsearch or OpenSearch queries and clients work with Infino?
Infino implements a supported subset of the Elasticsearch / OpenSearch Query DSL, so compatible clients and queries keep their request shape. Ranked results may differ, and Lucene-specific analyzers, span queries, stop words, distance, and proximity require alternate queries. Clients that use supported bulk and index APIs can be repointed after validating ingest processors, lifecycle policies, and data-stream behavior during a dual run. Migration reindexes documents into Parquet.
Do I still have to manage a cluster?
No. Infino separates durable files in object storage from the compute that reads them. Capacity follows the query workload, while shard allocation, replica placement, and rebalancing leave the operating model.
Does Infino support hybrid search like Elasticsearch’s RRF?
Yes. BM25 and vector results are fused with reciprocal rank fusion inside a single query, in one pass over the same files. The same fusion is callable from SQL as a table function, so hybrid results can join against the rest of your data.
Does Infino include dashboards?
No. Infino does not include native dashboards. Build dashboards through the Infino MCP server; infino-analytics is a reference implementation.
Why would I use Elasticsearch or OpenSearch instead?
Elasticsearch or OpenSearch remains the stronger fit when the workload depends on Kibana or OpenSearch Dashboards, Lucene analyzers, span queries, stop words, distance, proximity, or ingest and lifecycle behavior outside Infino’s supported API subset.
Can Infino replace the ELK stack for log search?
Infino can replace Elasticsearch for supported log-search workloads, and compatible ingest clients can continue sending data through the API. Kibana, APM, alerting, and other Elastic-stack applications remain separate migration decisions.
How does Infino handle high availability without replica shards?
The object store retains the durable data. Replacement compute reads the same bucket and rebuilds its local cache.
How do I migrate from Elasticsearch or OpenSearch to Infino?
Export with the scroll API or the pipeline you already have, append into Infino tables over REST in Arrow or JSON, and dual-run representative traffic before routing reads differently. Queries inside Infino’s supported Query DSL subset keep their request shape; Lucene-specific features use alternate queries. Migration reindexes documents from source records because Lucene segments use a different format.
What license is Infino under compared to Elasticsearch and OpenSearch?
Infino’s core engine is Apache-2.0. OpenSearch is Apache-2.0. Elasticsearch is triple-licensed under AGPLv3, SSPL, and the Elastic License 2.0.
Who builds Infino?
The team that built and ran OpenSearch at AWS.