VAST Data Claims Its Cloud Event Broker Costs Far Less Than Confluent Cloud

A Kafka-compatible broker built into the VAST AI Operating System

According to VAST Data, VAST on Cloud (VoC) places the VAST Event Broker inside the VAST AI Operating System, which runs on storage-optimized virtual machines deployed as virtual EBoxes (Everything Boxes). The broker speaks the Kafka protocol, so existing client libraries, APIs and tools continue to work, the company says.

Instead of keeping partition logs on individual broker nodes, message topics are stored natively as tables in VAST DataBase. JSON payloads are expanded into queryable columns as they land. Query engines including Trino, Presto and Apache Spark can read those topic tables through native VAST connectors, which VAST says removes the need for ETL pipelines or a separate analytical lakehouse.

Shared-nothing Kafka versus disaggregated shared-everything

VAST contrasts its design with standard Apache Kafka, where brokers coordinate partition leadership and keep local log state. Writes are replicated to follower brokers in distinct availability zones to meet a replication factor of three. VAST argues that this consumes broker memory, CPU and east-west network bandwidth, and that rebalancing partitions after a node failure or ingestion growth generates inter-broker traffic that competes with producer writes and client reads.

The company acknowledges that managed services such as Confluent Cloud reduce some of these constraints. It describes Confluent's Kora engine as using local NVMe storage for active log segments, replicating across AZs, and offloading closed segments to object storage such as Amazon S3. VAST notes, however, that it retains Kafka's partition-centric execution model.

In VAST's virtual EBox model, the CNode data services and DNode storage functions share one VM. Each EBox runs three containers: one CNode and two DNode. Every CNode can reach the cluster's shared backend data. Event messages are inserted as rows in the topic's table, with the Kafka offset serving as the row ID. VAST says this guarantees per-partition ordering and preserves key, value, headers and timestamp as columns. Capacity is added by adding EBox VMs, without migrating partition logs between brokers.

Data protection and the cost comparison

VAST says three-way replication in Kafka-based platforms results in 200% data capacity overhead. VAST on Cloud instead uses erasure coding across EBoxes, which the company says requires between 2.7% and 20% parity overhead depending on the number of VMs and resiliency type.

On AWS and Microsoft Azure, Cloud-HA adds a persistent layer. Metadata and write buffers are synchronously persisted to attachable block storage, while new data is continuously streamed to object storage. After a full AZ failure, block volumes are reattached to new VM instances, which takes 3 to 15 minutes depending on cluster size, according to VAST. VAST also applies similarity-based data reduction before data is committed to flash.

The baseline workload in the analysis is 4,000 MB/s of sustained ingress, a fanout ratio of 2.0, a five-day (120-hour) retention period and 1.0 KB average events, over a 730-hour month. That equates to 10,025.02 TB ingested and 20,050.05 TB egressed per month, with 1,647.95 TB of retained logical event volume.

Under these parameters, VAST puts VAST on Cloud at $238,387 per month, or $23.78 per terabyte ingested. Confluent Cloud Enterprise comes to $1,106,530 per month, or $110.38 per terabyte ingested, driven by data egress across multiple consumers and post-replication storage charges, according to the company.

VAST adds that an Enterprise cluster is capped at 32 eCKUs (1,920 MB/s ingress), so the workload needs at least three Enterprise clusters. Because the analysis prices them as a single pool, VAST says the Confluent figure is a floor.

What it means for streaming teams

The analysis is a vendor-authored model, and the published text covers only the configured workload described above. Teams running high-throughput, multi-consumer streams with multi-day retention are the ones for whom the egress and replicated-storage line items matter most, as VAST frames it. Anyone evaluating the claim would need to test it against their own throughput, retention and fanout profile.