VAST Data
DataEngine & Event Broker
IntermediateBring compute to the data - serverless functions triggered by events, on a Kafka-compatible broker built into the platform.
Bring compute to the data
The default pattern for processing data is backwards: data lands in storage, then a separate pipeline copies it out to a compute cluster, transforms it, and writes results back somewhere else. Every hop costs money, adds latency, and creates a stale copy. For AI this is fatal - embeddings and enrichment lag behind ingest, so the context your models retrieve is always a batch window out of date.
DataEngine inverts the model: run the function where the data already is. No ETL job to schedule, no second cluster to feed, no extra copy to keep consistent. The compute is event-driven and stateless, so it only runs when new data actually arrives.
the old way
Move data → compute
Copy out, transform, copy back. N hops, N copies, N failure points.
the old way
Scheduled batch
A cron/Spark job sweeps periodically - context is always one window stale.
DataEngine
Compute → data
Functions run in-situ, triggered per event. Fresh by construction.
DataEngine: serverless functions & triggers
GADataEngine is an event-driven serverless compute fabric that runs functions on data where it lands. Serverless functions & triggers went GA on Nov 11, 2025. It has three execution modes that compose into one in-situ pipeline.
Event Triggers
Delivered via the Event Broker, they detect file, object, and metadata events in real time and invoke your code.
Serverless Python Functions
Standard Docker containers registered in VAST. They run in stateless containers that scale elastically and execute only when triggered.
Containerized Engines
Longer-lived containerized workloads for heavier processing that still runs next to the data.
Event-driven pipeline
Object lands
A new image/document is written to a VAST view (S3, NFS, or SMB). The write hits storage directly - no staging copy.
Compute runs where the data lands - no copy out to a separate cluster and no scheduled batch job. The whole loop completes per object, as it arrives.
Use cases
Auto-embedding on ingest
Image resize + inference (e.g. NVIDIA NIM tagging)
Transformation / enrichment pipelines
Real-time metadata generation
A function's lifecycle: code → container → trigger → in-situ run
You ship a function the same way you ship any container - the only new steps are registering it in VAST and binding it to a data event. Step through the lifecycle below.
Write Python locally
Author a standard Python function - your embedder, classifier, transformer, or enrichment logic. No proprietary SDK lock-in; ordinary code and libraries.
def handle(event):
obj = read(event.path)
vec = embed(obj) # NIM, OSS model…
return {"vector": vec}Event Broker: Kafka-compatible, stateless, storage-backed
GAThe Event Broker is a real-time event streaming engine built into the platform - it removes the need for a separate Kafka cluster and unifies streaming, storage, and analytics. Announced Feb 19, 2025 and available Mar 2025.
It is Kafka API-compatible, so existing producers and consumers work unchanged - but its brokers are stateless. There is no per-broker persistent state; durability and resilience come from VAST's global storage. Streams flow directly into VAST DataBase tables for instant correlation across structured and unstructured data.
Broker state
Stateless brokers - no per-broker persistent state to manage
Durability
Durability comes from VAST global storage - no replica fan-out
Cluster
Built into the platform - no separate cluster to operate
Path to analytics
Streams land directly as VAST DataBase tables - query immediately
Rebalancing
No data to move on broker change - state lives in storage
Vendor-reported throughput
10x+
vs Kafka on like-for-like hardware
500M+
messages/sec on the largest clusters
136M
msgs/sec in a separate benchmark blog
Figures are VAST-reported claims (announced Feb 19, 2025; available Mar 2025). The 500M+ and 10x+ numbers come from VAST's announcement; 136M msgs/sec is cited in a separate VAST benchmark blog. Independent results will vary with hardware, message size, and configuration.
Streams as tables: unifying streaming + analytics
Because brokers are stateless and storage is the source of truth, a stream is not a separate artifact you later ETL into a warehouse - it is a queryable table the moment it lands. The same record can be consumed as a Kafka message and joined against historical structured data in one query, with no copy in between.
One landing zone, two access patterns
Producers write via the Kafka API; analysts and agents read the same data as Database tables. No connector to maintain, no schema drift between the stream and the warehouse.
Correlate live + historical
Join an incoming event stream against months of prior data instantly - the latency floor is query time, not an ingest pipeline window.
Why this matters for AI
Together, DataEngine and the Event Broker make data active. Embeddings and enrichment happen automatically as data arrives, so the context your RAG and agent systems retrieve stays fresh in real time - not as of the last batch run.
DataEngine → active data
Auto-embed and enrich on ingest. RAG indexes and agent memory are updated as the underlying data changes, eliminating the staleness gap between “data written” and “data usable.”
Event Broker → the trigger backbone
The broker is what lets agents and functions act on incoming data with sub-second latency - the nervous system that turns new data into immediate action.