Early preview: invite-only beta, not live yet

Data pipelines in SQL. Every run in its own machine.

Write one SELECT. Point it at a source and a sink. Waddle runs it on DuckDB inside an isolated microVM that starts in about half a second and is deleted when the run ends, with checks that stop a bad load before it lands.

Read the docs How it worksHosted service: not open yet

terminal

$ waddle init orders-sync
$ waddle validate orders-sync/pipeline.toml
ok: my-pipeline
$ waddle run orders-sync/pipeline.toml --state state
{"rows_in":1000,"rows_out":667,"watermark":"2026-02-11 16:00:00","seconds":3.7}

Four ways to use it

The same pipeline files, wherever you work.

working in the prototype

CLI

One local program. Validate and run a pipeline on your own machine with no account and nothing uploaded. Later it also deploys to the hosted service.

waddle run pipeline.toml

planned

API

REST with a generated OpenAPI document: pipelines, secrets, runs, schedules, webhooks and usage.

POST /v1/pipelines/{id}/runs

planned

MCP

Let an AI assistant define, run and inspect pipelines through a local server or a hosted endpoint.

POST /mcp

planned

Web console

A SQL editor and run history. DuckDB runs in your browser to preview a transform on a sample, so the sample never leaves it.

dpaas.dev/app

How it works

Two files, one run.

Write

A short TOML file names the source, the sink, the optional watermark and the checks. A SQL file holds one SELECT over the source table.

Run

A fresh microVM loads the source, then locks itself down: no files, no network, no extensions. Only then does your SQL run. A second connection that never saw your SQL writes the sink.

Verify

Checks run before the write. After the write the sink is read back and compared. The watermark is saved only when the sink succeeded, so a failed run repeats safely.

pipeline.toml

name = "orders-sync"
sql  = "orders.sql"

[source]
kind    = "postgres"
dsn_env = "SRC_DSN"      # the name of a secret, never the secret
table   = "orders"

[sink]
kind    = "file"
url     = "s3://acme-data/orders.parquet"
format  = "parquet"

[incremental]
column  = "updated_at"
initial = "1970-01-01"

[[checks]]
rule = "not_null"
column = "order_id"
[[checks]]
rule = "reconcile"

orders.sql

-- the source is the table `src`
SELECT order_id, customer_id, amount, updated_at
FROM src
WHERE updated_at > $watermark

Measured, not promised

What the prototype did.

0.6 smicroVM boot with the image cached

28 sthe first time a new image version is pulled

6 of 6escape attempts refused after lockdown, inside the VM

1,000 to 667rows read from R2, filtered and written back, then read back

Prototype measurements from October 2026 on one region and a small plan, with a 256 MiB machine. They show what is possible, not a service level. Warm boot and cold image pull are different numbers; both are shown on purpose.

Sources and sinks

What works, what is planned.

Connector	Status	Notes
Files: CSV, JSON, Parquet over HTTPS, S3, R2	working	Read and write tested against Cloudflare R2, including a read-back check.
Postgres (source and sink)	working	Append, replace and upsert; tested locally with incremental loads. Not yet run inside a hosted VM.
MySQL, SQLite	planned	The DuckDB extensions load inside the VM; the pipeline connectors are not written.
Iceberg, Delta, DuckLake	planned	Extensions load inside the VM; DuckLake on object storage is the first lake sink.
BigQuery, Snowflake	planned	Untested. May need runner-side client code.
SaaS APIs (Stripe, GitHub and so on)	not in v1	A deliberate cut to keep the first version small.

FAQ

Questions people ask first.

What does this do that DuckDB alone does not?

DuckDB runs your query. Waddle adds what you would otherwise script around it: source and sink connectors, incremental state (the watermark), schedules, checks that stop a bad run before it writes, a read-back to confirm what landed, run history and metering.

Why a microVM for every run?

Your SQL is code from a user. Each run gets a fresh isolated machine that holds nothing from a previous run and is deleted when it finishes. On a cached image it starts in about 0.6 seconds, measured in our prototype.

Is it live?

No. This is an early preview. A prototype runs end to end and is described honestly on this site; the hosted service, billing and sign-in do not exist yet. The beta will be invite-only.

How much data can a run handle?

The target is up to about 10 GB per run on a single machine. Larger jobs, streaming and change-data-capture are not planned for the first version.

Which sources and sinks?

Files (CSV, JSON, Parquet over HTTPS, S3 or R2) and Postgres are working in the prototype. MySQL, SQLite, lakes and warehouses are planned. Connectors for SaaS APIs are deliberately not in the first version.

Will I be able to leave?

Pipelines are a plain TOML file and a SQL file, and the CLI runs the same files on your own machine with no account. Your sink is your own storage.

Beta access

Invite-only, and not open yet.

Sign-in with GitHub opens when the private beta starts. Until then there is nothing to buy and no account to create. The CLI and the file formats are the part you can read about today in the docs.