Superpower Daily
Salesforce and Anthropic Put 37 Sales Skills Inside Claude With...Google Puts Gemini 3.5 Transcribe in Preview With Live and Reco...Lam Breaks Ground on Oregon Lab, First Step in $3B AI-Chip R&D...Hugging Face Explains DeepSeek’s Matched Shift From MoE Experts...States Halt or Tighten AI Data Center Growth as a Cross-Partisa...Rocket Money’s Rowan Cancels Subscriptions by Text, Pushing Fin...Salesforce and Anthropic Put 37 Sales Skills Inside Claude With...Google Puts Gemini 3.5 Transcribe in Preview With Live and Reco...Lam Breaks Ground on Oregon Lab, First Step in $3B AI-Chip R&D...Hugging Face Explains DeepSeek’s Matched Shift From MoE Experts...States Halt or Tighten AI Data Center Growth as a Cross-Partisa...Rocket Money’s Rowan Cancels Subscriptions by Text, Pushing Fin...
Toolspublished

Estuary Makes Rust Runtime Default, With Exactly-Once Delivery Still Conditional

The change is built to keep related database updates together as they reach agents and operational systems. But a complete end-to-end delivery guarantee still relies on the receiving destination and connector.

By 3 min read
Estuary Makes Rust Runtime Default, With Exactly-Once Delivery Still Conditional
Sign in to save and react

Listen to this story

The audio brief

About 1:28
0:001:28
Read transcript
Estuary is making a Rust-based runtime the default for new data pipelines, while automatically migrating existing pipelines without customer intervention. The important change is how it handles related database updates: the runtime is designed to keep a complete transaction together as it moves toward AI agents, operational software, and data warehouses, instead of exposing those changes in pieces. That matters when fresh data can trigger an action. An agent or business system working from an incomplete view could respond before all the related updates have arrived. But transaction preservation inside Estuary is not the same as an exactly-once guarantee from source to destination. End-to-end exactly-once delivery still depends on the last hop. The destination needs to support transactions, or the connector needs to make writes idempotent, meaning a repeated write produces the same result as a single write. Otherwise, direct writes to a non-transactional destination may use at-least-once delivery, where duplicates are possible. Estuary says the runtime handles workloads ranging from millisecond streams to multi-hour loads, and that a worker can process up to 200 gigabytes per hour, with more workers added as volume grows. Those figures are company-reported, not independently benchmarked. Together AI uses Estuary for inference-event data flowing into AWS and warehouse tables, but that example does not independently validate this runtime. The practical question is whether performance holds in customer environments—and whether each destination can preserve the end-to-end guarantee.

Story brief

3 key points

Estuary is rolling out a Rust-based runtime as the default for new pipelines and migrating existing ones without customer intervention. The runtime keeps related database changes together during processing, which is important when AI agents or operational systems act on live data. But Estuary cannot guarantee exactly-once delivery end to end by itself: the destination must support transactions, or the connector must...

  1. 01

    Existing pipelines are being migrated automatically; new pipelines use the Rust runtime by default.

  2. 02

    Workers reportedly process up to 200 GB per hour, with additional workers added as volume grows.

  3. 03

    Non-transactional destinations may receive duplicates under at-least-once semantics.

Estuary has started making a Rust-based runtime the default for new data pipelines, aiming to keep database transactions intact as information moves into AI agents, operational software, and warehouses. The key limitation sits at the last hop: exactly-once delivery across the full path depends on what the destination and connector can support.

A transaction is the unit that must arrive

The new runtime is designed to preserve the boundary around related database changes. That means downstream software is intended to receive a complete transaction rather than a partial set of changes from it. Estuary is applying that design to data headed for AI agents, operational software, and warehouses.

That distinction becomes more consequential when software uses fresh data to act, not merely to populate a dashboard. A system that receives related updates out of sequence can operate on an incomplete view; Estuary’s product claim is that its runtime keeps those related changes together through its own processing.

The guarantee changes at the destination

Transaction preservation inside the runtime is not the same as exactly-once behavior from source to destination. End-to-end exactly-once delivery is available when the destination supports transactions, or when a connector can apply changes idempotently—meaning a repeated operation produces the same result as one application.

Direct writes to a non-transactional destination may instead provide at-least-once semantics. In that model, a record can be delivered more than once, so the destination or connector must be equipped to handle duplication if a workflow requires an end-to-end exactly-once result.

A single runtime across very different loads

Estuary says the Rust runtime spans workloads from millisecond streams to multi-hour loads, and from kilobytes to hundreds of petabytes. Existing pipelines are being migrated without customer intervention, while new pipelines now use the runtime by default.

The company also says a worker can process as much as 200 GB per hour and that workers can be added as volumes increase. That throughput figure is company-reported and has not been independently benchmarked in the published materials, so it does not yet establish performance across customer environments.

Inference telemetry shows the target workload

Together AI uses Estuary to move structured inference events into AWS and warehouse tables. The resulting data supports analysis of utilization, serving economics, and service-level commitments, illustrating the high-volume machine activity Estuary wants to handle quickly and completely enough for operational use.

The deployment example concerns Estuary’s broader platform rather than an independently measured rollout of the new Rust runtime. The practical test for the rewrite is therefore twofold: whether its stated performance holds under customer workloads, and whether customers’ particular destinations preserve the end-to-end guarantee Estuary is selling.

Related coverage

Continue reading