Infino: a search engine that treats Parquet on object storage as the database

The problem: search indexes that duplicate your data

Most search stacks keep a separate index, often in Elasticsearch or OpenSearch, and you pay for storage and sync. Infino takes a different route: the data stays in Parquet on object storage, and the index is embedded in the same file. The README states that text and numeric data is stored as spec-compliant Parquet, so anything that reads Parquet can read your data. This targets teams that already warehouse data in Parquet and want to query it without copying it into a dedicated search engine. The intended users are agent builders and analytics engineers who need keyword, vector, and SQL access to the same rows.

How a superfile splices indexes into Parquet

The core mechanism is the 'superfile'. The README explains that a superfile is a spec-compliant Parquet file with embedded BM25 and vector index regions spliced in ahead of the standard Parquet footer. These regions are pointed at by `inf.*` key/value metadata keys. A conformant Parquet reader ignores those keys, so the columnar body opens in DuckDB, pandas, pyarrow, or DataFusion without any Infino in the read path and without an export step. The index is not a separate store; it lives inside the file. Writes are snapshot-isolated with atomic commits, which suggests an immutable, copy-on-write model. That design explains why the benchmark claims warm BM25 queries in the microsecond range on a 1-million-document index, though the README does not detail the hardware or query distribution.

Getting it running: three language bindings, one URI scheme

Installation is straightforward per language. Python uses `pip install infino` or `uv pip install infino`. Node uses `npm install @infino-ai/infino`. Rust uses `cargo add infino`. The quickstart shows a Python example that connects to `memory://` for in-process use, or `./data` for disk persistence. The Node API is synchronous, with plain records out and `_id` returned as a JavaScript `bigint`. The Rust code uses `infino::connect` and `IndexSpec` to define a table with a vector column. The README gives a concrete schema with fields like `source` and `body`, and an `IndexSpec().fts("body")` to enable full-text search. For cloud storage, the backend is chosen by URI scheme: `s3://`, `az://`, `gs://`, or a bare path. Credentials go through `ConnectOptions` using `object_store` config strings like `aws_access_key_id` and `aws_region`. The README is explicit that Infino reads no credentials from the environment, so you must pass them or rely on ambient cloud identity.

The one-directional Parquet compatibility trap

The README is candid about a serious limitation: the compatibility is one-directional. Standard tools can read a superfile's columns with no export step, but rewriting it through a generic Parquet writer, such as `pyarrow.parquet.write_table`, produces valid Parquet that has silently dropped the embedded BM25 and vector indexes. It is no longer a superfile. This means any pipeline that re-writes Parquet files, whether for compaction, schema evolution, or ETL, will strip the search capability. If your workflow depends on external tools modifying those files, you will lose the index without warning. The README warns about this explicitly, which is good, but it is a fundamental constraint that makes Infino unsuitable for environments where Parquet files are shared and rewritten by other systems.

Hybrid search and SQL joins across tables

Infino supports multi-modal queries: keyword (BM25), vector, and SQL over the same rows. The README mentions hybrid search and SQL joins across tables as distinct features. The architecture suggests that a single query can combine these modes, which is useful for agent retrieval where you might filter by vector similarity and then apply a SQL condition. The README does not provide a full example of a hybrid query in the truncated text, but the table of contents lists 'Hybrid search' and 'SQL joins across tables' as sections, implying these are first-class capabilities. The ability to run SQL joins directly on Parquet without an external query engine is a differentiator, though the exact join performance characteristics are not documented in the provided material.

Maintenance and upgrade cost

The project is under active development, with recent releases v0.5.12, v0.5.11, and v0.5.10 pushed on consecutive days in August 2026. That rapid release cadence suggests frequent fixes and feature additions, but it also means you will need to track upgrades closely. The README has a 'Stability' section in its contents, but the truncated text does not include its content. You should read that section before adopting. The license is Apache-2.0, which is permissive for commercial use, but the project is young, and the API may change between minor versions. The Rust crate is versioned as `0.1` in the Cargo example, which is a signal that the API is not yet stable. The Python and Node bindings are built with PyO3 and maturin, and the Node API is synchronous, which could be a performance bottleneck for high-concurrency applications. There is no mention of a migration guide or upgrade path in the provided material.

A real alternative: DuckDB with its own FTS extension

If you need SQL and Parquet reading, DuckDB is a direct alternative. DuckDB reads Parquet natively and has a full-text search extension, though it does not embed vector indexes in the same way. The key difference is that DuckDB treats Parquet as an external format and builds its own indexes in memory or on disk, not inside the Parquet file. That means you can rewrite the Parquet with any tool and still query it with DuckDB, but you lose the embedded index persistence. Infino's approach gives you a self-contained file with index and data together, which is convenient for distribution, but it sacrifices the write compatibility. For vector search, you would need to pair DuckDB with a separate vector database like LanceDB or Qdrant, whereas Infino combines all three query types in one engine. The choice comes down to whether you prefer a single-file superfile or a more conventional separation of storage and index.

Editorial conclusion

Adopt Infino if you need search over large Parquet datasets already in object storage, want to avoid a separate index store, and can accept the one-directional Parquet compatibility. Do not adopt it if you require bidirectional interoperability with generic Parquet writers, or if your workload needs frequent in-place updates, since the design favors immutable snapshots. Before committing, verify the stability section in the README, test the exact S3 or Azure credential flow with your cloud provider, and run the benchmark suite on your own data shape to confirm the microsecond BM25 claims hold outside the 1-million-document warm index. Also confirm that the Node API's synchronous behavior and bigint `_id` fit your client expectations.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes