Fast search at scale.
Infino is a search engine on object storage. Full-text search, vectors, and SQL, natively in Parquet.
More
efficient.
Colocating indexes with data, touching far fewer bytes per query, and building native to object storage collapses the request path — and the bill that comes with it.
BM25 posting lists and vector clusters live in the same Parquet file as the data. A query is a handful of byte-range GETs, not a fan-out across services.
Footer + at most one FTS region + at most one vector cluster region. No warm-up, no hot replicas — first query off cold storage is the steady-state query.
Designed against the byte-range GET model from day one. No translation layer over a disk-era engine, no cluster to keep alive between queries.
Hybrid BM25 + ANN retrieval with predictable tail latency, so retrieval-augmented agents don't stall on the slowest call in the chain.
Filters, top-k, and rerank execute next to the bytes. The reader returns ranked hits, not raw rows for a downstream engine to sort.
Indexes sit on S3 alongside the data. Spin compute up for a query, down after — search cost tracks usage, not fleet size.
One copy
of your data.
A purpose-built search format that puts full-text indexes, vector embeddings, and SQL data inside a single Parquet file on object storage. No second store to sync, no third store to reconcile. Full compatibility with your warehouse.
Vector embeddings are stored alongside the data inside the Parquet files — no separate vector database to manage.
Full-text indexes are embedded in Parquet alongside the data. No Elasticsearch fleet to scale and re-index.
S3, GCS, Azure Blob. Storage and compute scale independently — search stays cheap as data grows.
Files remain valid Apache Parquet. Other engines can read them as a normal columnar table — you aren't locked into a proprietary store to query your own data.
Drop-in with your existing warehouse. Query the same Parquet files from Snowflake, Databricks, BigQuery, or DuckDB — no migration, no duplication.
One landing zone feeds search, vectors, and SQL. No pipelines copying data into a search cluster, a vector store, and a warehouse to keep three systems in sync.
Built for
agents.
Hybrid queries combine BM25, vector, and SQL in a single pass over consolidated data. Agents retrieve full documents instead of fragments, which reduces chunking overhead and the number of round trips between the agent and the LLM.
BM25, vector ANN, and SQL filters resolve in a single pass over the same Parquet file, returning a unified ranked result set.
Indexes operate at the document level, so retrieved results carry their full surrounding context rather than a fixed-size fragment.
Text, embeddings, structured columns, and metadata live in the same row group. A query can filter, search by similarity, and rank by relevance in one pass.
Every hit is addressable back to its row in the underlying Parquet file, so agents can cite and re-read the original record.
New Parquet files become queryable as soon as they land on object storage — no separate embedding or index-build step before the data is searchable.
Each query resolves through a bounded number of byte-range reads, which keeps retrieval latency stable as a tool call inside an agent loop.
Benchmarks
Head-to-head against the leading search engines, vector databases, and SQL engines. Coming soon.
Preview ComparisonCompare
Side by side with search engines, vector databases, and SQL engines on cost, latency, and operational footprint.
See the comparison DeploymentEnterprise
A full AI stack on your core engine — UI, RBAC, Fino, connectors, and federated search — inside your VPC or air-gapped environment.
Learn more