infino architecture

Architecture

Infino writes Parquet to object storage to power search. Keep a single copy of your data so every tool in your stack reads the same source of truth.

Infino writes BM25 and vector indexes into the Parquet files. file layout →

Hybrid search reads BM25 and vector index regions inside each Parquet file. example query →

SQL runs on DataFusion with BM25, vector, and hybrid search as table-valued functions. SQL example →

A supported Query DSL subset lets compatible Elasticsearch and OpenSearch clients query Parquet. migration path →

Object storage holds the durable data; RAM and NVMe cache hot byte ranges. cache path →

Infino has table-level integrations with Iceberg, Delta Lake, and Hudi. catalog integration →

Files remain standard Parquet columns readable by Snowflake, Databricks, DuckDB, Trino, and ClickHouse. warehouse fit →

hover a section to learn more

infino explain files

Each chunk of a table is one self-contained file, a superfile.

Columns and both search indexes, keyword and vector, live in the same file.
It's a valid Apache Parquet file, so DuckDB, pandas, and Spark open the same bytes.

A table is its manifest: the many superfiles it currently points to. Infino calls that whole, manifest-tracked table a supertable.

If you have used Iceberg or Delta Lake, this is the same idea: immutable data files plus a small pointer that commits atomically. Here the files also carry the search indexes.
Switching manifests is one atomic step, so a reader sees the table before a write or after it.

The engine stores nothing permanently.

It fetches the byte ranges a query needs and keeps frequently used data on local disk, the way a warehouse caches hot partitions.

The same build runs on any object store, chosen once at startup.

Amazon S3, Azure Blob Storage, Google Cloud Storage, or a local disk.
Run it serverless on Infino Cloud (beta): multi-tenant, metered on usage, with support and SLAs.
Or run the same engine yourself, on-premise or in your cloud.

infino init