Infino vs the alternatives

They keep the data on the cluster’s own disks. Infino keeps it in your object-storage bucket and searches it there.

• no cluster to size, shard, or reindex
• no replicas: the object store is the durability
• no second copy of data you already store
• retention billed at object-storage rates, not hot-cluster rates

In production, retrieval usually needs keyword matching for the queries embeddings miss, filters over metadata, joins against the catalog, and one ranking across all of it.

• a vector database covers the vector part; the other three become separate systems to run
• Infino covers all four in one engine

No. Warehouses answer analytical questions: scans, joins, aggregations, BI. Infino answers retrieval questions: the right rows in milliseconds, by keyword, similarity, or predicate.

• same files: Infino’s indexes live inside the Parquet your warehouse already reads
• DuckDB and Spark still open them as plain Parquet

A stateless gateway in front of per-database engine workers, all over one object-storage bucket. Storage and compute scale apart, so there is no cluster or replica set to size and operate.

• data lives in your object store as standard Parquet, not on the engine’s own disks
• compute is stateless: workers start per database on demand, across nodes for high availability
• run it managed as Infino Cloud, or in your own cloud from the same codebase

Warm queries land in single-digit to low-double-digit milliseconds on real AWS S3. The index layout reads only the byte ranges a query touches, and hot data is cached on the worker.

• 10M documents on real S3, warm p50: keyword ~7ms, vector ~10ms, hybrid ~13ms
• a cold shard pays the first object fetch, then serves from cache
• see the benchmarks for the full numbers and the method behind them

You write with append, update, and delete. Each write publishes atomically as a commit, so a query sees the whole batch or none of it, never a half-written one.

• a commit writes new Parquet files plus a new manifest, then swaps the current-manifest pointer in one atomic step
• existing files are never mutated: updates and deletes publish a new snapshot over different files
• concurrent writers are guarded, so a writer on a stale manifest retries instead of clobbering another commit
• read freshness follows the table’s consistency policy, applied on every query, with no manual reindex step

An agent, or a person, can go from install to a verified first query in one sandbox session, with nothing to stand up first.

• infino: pip install, five lines to a first query
• lancedb: pip install · tantivy: cargo add, keyword only
• pgvector: needs a running Postgres first
• qdrant / weaviate: need a server; qdrant ships a python local mode
• elasticsearch / opensearch: need a cluster or a managed service

Whether one engine runs keyword and vector search and ranks the results together.

• infino: BM25 + vector, fused with RRF in one query
• elasticsearch / opensearch: BM25 + kNN + RRF
• lancedb: full-text + vector
• pgvector: tsvector and pgvector are separate; you fuse the rankings by hand
• qdrant / weaviate: vector-first, with sparse-vector add-ons
• tantivy: keyword only

Whether you can run SQL over the same rows the search indexes cover.

• infino: SQL through DataFusion; search runs as table functions inside the query
• pgvector: full Postgres SQL
• lancedb: SQL filters through DataFusion
• elasticsearch / opensearch: partial, ES|QL and a SQL plugin
• qdrant, weaviate, tantivy: no SQL

Whether other engines can read the stored data without going through the one that wrote it.

• infino: standard Parquet; DuckDB, pandas, and Spark open the same files
• lancedb: Lance format, open but read through its own readers
• pgvector: readable by anything that talks to Postgres
• elasticsearch, opensearch, qdrant, weaviate, tantivy: engine-private formats

• infino: Apache-2
• opensearch: Apache-2 · elasticsearch: AGPL / ELv2
• qdrant / weaviate: Apache-2 / BSD-3
• pgvector: PostgreSQL license
• lancedb: Apache-2
• tantivy: MIT