Infino raises $7.5M to build one retrieval layer for all your agents
We (Ekechi Nwokah, Vinay Kakade, Asif Makhani, and Murali Krishna) have spent years building and operating ML and search systems across Amazon, Google, and LinkedIn, including AWS OpenSearch.
During those years, query patterns were predictable. Humans or applications queried. Search ran on a search database. Analytics ran in a warehouse. Vector databases enabled approximate queries and unlocked a new class of use cases, but they did not fundamentally change those query patterns. Each query ran on its own system, with its own copy of the data, its own ingestion pipeline, and its own team to run it.
Agents changed the paradigm completely. They do not query like humans. They query in parallel. They query in rapid sequence. They query with lots of keywords. They also query in natural language, which opens yet another class of queries to tackle. These are all patterns that traditional data stores were not optimized to handle efficiently.
That is why we built Infino: to enable any agent to query data at scale, in one query, over one copy of the data.
The first challenge: reads
Take a routine query from an agent: How many errors last night mention disk full or look like a capacity incident? Which service had them?
There are five different query operations hiding inside it. How many is a count. Which service is a grouping. Errors last night is a time filter. Disk full is keyword search. Look like a capacity incident is semantic search.
Today, those operations often span a search engine, a vector database, and a warehouse. The agent has to call each one and then spend additional model turns combining the results.
So we started by fixing the query layer. Infino embeds retrieval functions directly in SQL, so the whole question can be expressed in one query:
SELECT service, count(*) AS hits FROM hybrid_search( 'logs', 'body', 'disk full', 'embedding', :q, 1000 ) WHERE level = 'error' AND ts > now() - interval '24 hours' GROUP BY service ORDER BY hits DESC;
One English question becomes one query that completes in milliseconds. The important part is not SQL itself. Keyword search, semantic search, filtering, aggregation, and grouping can happen together instead of forcing the agent to orchestrate several systems and reason over a pile of intermediate results. Filtered to the search engines on ClickBench, Infino ranks #1 for SQL analytics (combined metric). The same engine runs keyword and vector search, so those combined queries get fast execution. The benchmarks page has the numbers and how to reproduce them.
There is one more challenge. Even when retrieval is fast, we are finding that agents spend a lot of time in retrieval loops. They formulate a query, search, decide whether the results are good enough, try something else, validate the answer, and repeat. Infino integrates targeted inference models with the retrieval engine so these simpler tasks can be handled faster and more cheaply than with frontier models. Tighter integration of retrieval and inference means fewer calls, fewer model turns, fewer tokens, and ultimately lower query latency.
The second challenge: writes
The other half of Infino is how the data is stored. Instead of maintaining separate copies for search, vectors, and analytics, Infino keeps a single copy in Parquet on object storage.
Infino stores indexes inside the Parquet files to make retrieval fast, while the underlying data remains Parquet. Iceberg and Hudi can manage the same files, and any Parquet reader can still read them. One copy of the data can therefore serve the different paths an agent takes to query it.
We also wanted that path from data to query to be simpler than with traditional data stores. Setting up clusters, nodes, shards, and headcount is a lot of complexity just to query data. With Infino, you can point at Parquet or JSON, ingest the data, then point your agent at Infino and start querying.
With this architecture, Infino is designed to be roughly 10x cheaper than traditional search or analytics infrastructure. The durable copy stays in your bucket while search, vectors, and SQL all run over it. That means agents can query the underlying data without having to harmonize results across a collection of SaaS tools and MCP layers, and you do not need large stateful clusters just to keep a searchable copy of the data alive.
Where we are today
We are already working at multi-billion-row scale with customers across government, document processing, CAD design, and real-time analytics, with more deployments underway.
Today we are also announcing that we have raised $7.5 million, led by Bessemer Venture Partners, with participation from Collide Capital, AIN Ventures, Integral Ventures, Echo VC, and other strategic investors.
We are using the funding to keep building the retrieval layer we think agents need: one fast, inexpensive place to search, rank, filter, join, aggregate, infer, and query their data without requiring three different systems underneath them.