MotherDuck buys Tower to put an agent runtime behind its data warehouse
The acquisition turns the runtime already underneath Flights into a roadmap for callable data APIs, orchestrated data agents and prompt-built applications.
The acquisition
MotherDuck has acquired Tower Computing, the runtime-infrastructure company whose technology already powers MotherDuck Flights. In the announcement, CEO Jordan Tigani says Tower supplies the hosting, orchestration and scheduling needed to run LLM-written data pipelines, while also providing sandboxing, observability and reliability that the model itself does not provide. MotherDuck announced the deal on August 25.
That makes this less a conventional product bolt-on than the purchase of an execution layer MotherDuck was already using. MotherDuck says it built Flights on Tower and launched the feature within weeks; Flights lets users host, schedule and orchestrate code generated for data movement and pipeline work. The company traces the relationship back to an earlier effort to simplify data ingestion.
What MotherDuck plans to build
The roadmap has two concrete branches. First, Tower jobs can expose stable URLs, which MotherDuck plans to use so a Flight can become a custom data API. Second, MotherDuck says Tower’s runtime will support data-agent orchestration for work beyond ingestion, including cleaning and investigation. The announcement explicitly positions the runtime as a base for “flexible and robust data agents.”
MotherDuck also links the API path to Dives, its hosted visualization technology. Its example combines a Dive that displays restaurant recommendations with a Flight that lets users create or modify those recommendations, producing an interactive application rather than a read-only analytical answer. MotherDuck says Flights and Dives together can support secure, scalable applications built from a prompt.
Why it matters for analytics teams
Natural-language analytics products usually concentrate on generating a query or returning an answer. This deal points at the harder operational step after generation: executing code repeatedly, on a schedule, inside a sandbox, with enough observability to diagnose failure. MotherDuck’s own account is unusually direct that Claude supplied pipeline code while Tower supplied those runtime controls. That separation of responsibilities is central to the acquisition rationale.
For practitioners, the important boundary is therefore not only whether an agent produces correct SQL. It is whether generated work has an execution identity, constrained permissions, inspectable logs, retry behavior and a safe rollback path. MotherDuck’s post names sandboxing, scheduling, observability and reliability, but it does not publish detailed controls for secrets, network access, approvals or rollback in this announcement. Those implementation details remain the items to verify as the new agent and API capabilities arrive.
The acquisition closes the gap between MotherDuck’s answer layer and an application runtime, but the announcement is a roadmap as much as a release: Tower already powers Flights, while custom data APIs and broader data-agent orchestration are described as capabilities the deal will enable. Teams should distinguish what is running today from what MotherDuck says comes next.
sources
comments · 0