VAST Data

DataEngine & Event Broker

Intermediate

Bring 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

GA

DataEngine 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

1Object2Event3Serverless4Vector

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.

1

Write Python locally

Author a standard Python function - your embedder, classifier, transformer, or enrichment logic. No proprietary SDK lock-in; ordinary code and libraries.

artifacthandler.py
def handle(event):
    obj = read(event.path)
    vec = embed(obj)   # NIM, OSS model…
    return {"vector": vec}

Event Broker: Kafka-compatible, stateless, storage-backed

GA

The 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.

producerproducerbroker 1broker 2broker 3statelessVAST storage= DB tablesqueryable now

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

GA

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.