What changes when your search index lives on S3?

Infino describes a retrieval engine that keeps its full-text and vector search index directly on object storage (S3, GCS, Azure Blob) rather than local disks, because customer data already lives there and object storage offers scale and availability. Object storage changes the cost model: every random read is an HTTP GET that costs tens of milliseconds and is billed per request, so the primary optimization is minimizing round trips. To do that, Infino writes each immutable index unit as a single Parquet “superfile” containing rows plus embedded full-text and vector index regions, and groups many superfiles into a supertable. A compact manifest caches every superfile’s Parquet footer and index headers so opening a superfile requires no extra GET, reducing the cold cost from two round trips to one.

A separate term index maps each term to the superfiles that contain it and stores per-term metadata: document counts, a score bound for block-max pruning, and byte offsets of postings. The term index is sliced by term range so queries fetch only relevant slices; a single-term count can be answered from the term index alone (one test went from opening 141 superfiles to none). Queries fetch only needed byte ranges, merge nearby ranges into a single ranged GET, and reuse fetched bytes. A background disk cache downloads whole superfiles and memory-maps them for fast subsequent reads, with LRU eviction. Core algorithms - postings, BM25, block-max pruning - remain unchanged; what changed is the storage layer and the emphasis on eliminating network round trips.