Does Infino need a server?
No. Infino runs inside your application as a library. You add it (cargo add infino,
pip install infino, or the npm package) and open a connection to a storage root from
your own code; the engine, including SQL (DataFusion under the hood), runs in your
process. There is no wire protocol yet, so external SQL clients
can’t attach; SQL is reached through the connection’s query_sql. See
Opening Infino.
Is Infino a database?
Not in the transactional sense. Infino is a retrieval engine for search and analytics over data you keep as Parquet, not an OLTP database for transactions or row-level updates. Use it to search and retrieve alongside whatever system owns your writes.Is Infino a vector database?
It does what a vector database does, semantic nearest-neighbor search over your embeddings, without being a separate store you run. Vector search is one mode among full-text, hybrid, and SQL over a single copy of your data, and you bring your own embeddings.Is Infino a search engine?
It gives you ranked full-text (BM25) search without a standalone cluster. The inverted index is embedded in your Parquet files on object storage, and queries run inside your application.When should I use Infino, and when not?
Use it for RAG and agent retrieval that wants hybrid (keyword plus semantic) relevance over one store, for large mostly-cold corpora that must stay searchable, and to add search and vector over Parquet you already have. It is not a system of record: transactional, write-heavy workloads belong in an OLTP database. See Tradeoffs for the full envelope.How does Infino compare to search engines and vector databases?
Instead of running a search cluster, a vector database, and an analytics store as three systems with three copies of your data, Infino runs full-text, vector, and SQL over one copy of standard Parquet on object storage. For a capability-by-capability comparison against search engines, vector databases, lakehouse tables, and warehouses, see how Infino compares.How do concurrent writes work?
One writer is active per table at a time. Appends, updates, and deletes are staged on a writer and made durable by a single atomic commit. Nothing is persisted until the commit succeeds, and a reader sees either the pre-commit or the post-commit state, never a partial one. Across processes the commit is guarded: the pointer to the current manifest is swapped only if it hasn’t moved, so a writer working from a stale manifest can’t overwrite another’s commit. A conflicting publish refreshes from the current manifest and retries with backoff, up to a bounded number of attempts before surfacing a contention error. See Write, Commit pipeline, and Concurrency.How fresh are reads? What is the consistency model?
Snapshot isolation. A reader pins the manifest that is current when it opens and never observes a partially applied commit; publication is atomic, so a read returns the table as of its pinned snapshot. Read freshness under concurrent writers is governed by the table’s configured consistency policy and applied by the engine on every read; callers never refresh by hand. See Manifest and Lifecycle.How do multiple processes or hosts share a table?
Through storage, not a coordinator. For a persistent table the backend holds the superfiles, the manifest, and a pointer to the current manifest. A commit writes the new superfiles and manifest first, then swings the pointer in one atomic step, so any reader resolving the pointer lands on a complete manifest. Concurrent writers from different processes are serialized by that guarded pointer update (see concurrent writes above), so multiple processes or hosts can read and write the same table on shared object storage with no separate service. Verified bytests/supertable_concurrent_processes.rs;
see Storage.
Are writes durable and crash-safe?
Yes. Nothing is persisted until a commit, and a commit publishes atomically, so a crash mid-write leaves the previously committed snapshot intact, with no half-applied state. Committed superfiles surviving an abort mid-flight is verified bytests/supertable_commit_crash_localfs.rs.
Can DuckDB, pyarrow, or DataFusion read Infino’s files?
Yes. Each superfile is a valid Parquet file (it begins with Parquet data and ends with a standard Parquet footer), so DataFusion, DuckDB, and pyarrow can open it as a normal table and project columns, filter rows, and run SQL over the columnar data with no Infino-specific support. Compatibility is a property of the bytes, not a conversion step. See Parquet compatibility.Are the search indexes visible to ordinary Parquet readers?
The scalar and text columns are: they’re ordinary Parquet columns any reader sees. The full-text and vector index regions are not. They lie outside the row-group ranges described by the footer and are namespaced in the footer’s key-value metadata, so a standard reader simply skips them. Infino uses that same footer to locate the indexes when search is requested. Round-trip caveat: because the indexes live outside the standard Parquet structures, reading a superfile and rewriting it through a generic Parquet writer preserves the columns but drops the index regions. The output is still valid Parquet, but no longer searchable by Infino without re-indexing. See Parquet compatibility.How does SQL run with no server?
DataFusion executes in-process; you reach it through the connection’squery_sql, which resolves every table the query names through the catalog into
one engine, so joins and aggregations span tables. The retrievers are also SQL
table-valued functions (bm25_search, vector_search, token_match,
exact_match, hybrid_search), so search composes into a SQL plan as a
relation.
Does Infino compute embeddings, or do I bring my own?
You bring your own. Infino indexes the vectors you supply: compute them with any model and pass them in alongside your rows. See Embeddings.Which distance metrics does vector search support?
cosine (for normalized embeddings), l2sq (squared Euclidean), and negdot (dot
product). You set the metric on the vector index.
Does Infino do hybrid search?
Yes. BM25 and vector kNN are fused with reciprocal-rank fusion in one query, via thehybrid_search SQL function. See Hybrid search.
Can I filter vector search by other fields?
Yes. Use the pushdown text pre-filter onvector_search (the kNN ranks only matching
rows), or filter with SQL. See Vector search and the
SQL Reference.
Can I update and delete data?
Yes. Match rows by a predicate andupdate (1:1 replacement) or delete. Both require
durable storage (a path or s3://, not memory://). See Tables.
Which languages can I use Infino from?
A Rust core with Python (pip install infino) and Node.js (npm install @infino-ai/infino)
bindings.