How Infino works

The whole system is three layers over one bucket.

• A stateless gateway authenticates each request and routes it to a worker.
• Each database runs as its own engine process with a local cache.
• Object storage holds every byte. Workers are only compute over it, so any worker can serve any database, and more workers add capacity.

Your data is just 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. No sidecar indexes to keep in sync.
• A superfile is a valid Apache Parquet file, so DuckDB, pandas, and Spark open the same bytes as an ordinary table.

Files are never edited, only added

A table is its manifest: the list of files that make it up right now.

• A write adds new files and publishes a new manifest. It never edits the files already there.
• Switching manifests is one atomic step, so a reader sees the table before a write or after it, never halfway.
• Snapshots are cheap: an older manifest still points at files that are all present.

Storage and compute are separate

A worker stores nothing permanently. Object storage is the source of truth.

• It fetches byte ranges on demand and caches the hot parts on local disk.
• A cold file is served from storage while it loads in the background, then memory-mapped for local-disk speed.
• Storage and compute scale on their own, and you pay for each separately.

How a query runs

A query pins one snapshot, then prunes before reading a byte.

• Per-file summaries in the manifest, value ranges, a keyword presence filter, and vector centroids, skip files that cannot match.
• It fetches only the byte ranges the survivors need, searches them in parallel, and merges one ranked answer.
• Keyword, vector, and SQL share one pruning layer, so a hybrid query runs in a single pass.

See the numbers on real S3 →

A database is a process, started on demand

Creating a database is just metadata. Workers start on the first request.

• No worker runs until that first request, so an idle database costs only storage.
• The request starts the engine on at least two separate nodes, picked by the load each node reports.
• A worker serves one database and nothing else. That is the isolation boundary.
• If a node fails, another copy is already serving. Nothing is recovered: the data was on object storage, never on that node.

Run it managed, or in your own cloud

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 managed on our infrastructure, or in your own cloud account, from one codebase.
• Self-hosted, point it at a bucket in your account and run it yourself.

Run it managed →  ·  In your own cloud →