VAST Builds Trillion-Embedding Database

Diving deeper into

Renen Hallak, CEO of VAST Data, on AI agents creating infinite storage demand

Interview
We needed to build a new type of database that could store a trillion rows, because you now have a trillion vector embeddings
Analyzed 6 sources

This is the moment VAST stops looking like a storage vendor and starts looking like the data plane for AI systems. A trillion embeddings means the database is no longer indexing a few business records, it is holding machine readable representations of nearly every document, image, code file, and event an AI system might need to recall. That shifts the problem from simple storage capacity to fast retrieval, mixed data types, and huge numbers of simultaneous reads and writes.

  • A vector embedding is the numeric form of a file, image, paragraph, or query, so a trillion row database is really a memory system for AI. NVIDIA describes vector databases as stores for these embeddings, and Pinecone framed the core workflow as turning text or images into embeddings, storing them, then querying by similarity.
  • VAST is trying to collapse three layers into one system. Its DataStore keeps raw files and objects, its DataBase stores tables and vectors, and its DataEngine triggers compute when data changes. That matters because AI pipelines usually move data across separate storage, vector, and orchestration tools, which adds copies, delays, and governance gaps.
  • The closest comparison is standalone vector databases like Pinecone or Milvus, but VAST is positioning differently. Instead of a dedicated retrieval layer, it embeds vector search inside the same database and storage stack, and now claims hierarchical indexing that extends from billions toward trillions of vectors with lower cost at high concurrency.

The direction is toward AI infrastructure where retrieval, storage, and event driven compute run on the same substrate. If that architecture holds, VAST can expand from selling fast shared storage for GPU clusters into owning the database and execution layer that agentic applications depend on, which would put it on a direct path into territory now occupied by data warehouses, vector databases, and workflow engines at once.