The transformation is SQL, and you can read it before it runs.

This is the part competitors keep behind a visual mapping tool. We think the reason integration debt becomes unmanageable is that nobody can see what the transformation actually does, so ours is text, versioned, and reviewable by anyone who knows SQL.

Pipeline builder

Working version on the left of the toggle. Deployed on the right.

A pipeline is a set of declared sources, one or more SQL stages, and a single destination. What is running and what you are editing are never the same thing by accident.

1Sources are declared, each with a toggle for whether an update to it triggers a rerun.
2Stages run top to bottom. Each is SQL you can read, edit, and preview independently.
3The working and deployed split means a change is reviewed before it becomes live.
4The destination declares its storage tier and write mode rather than implying them.
Beetl's pipeline builder showing declared sources with trigger toggles, two SQL transformation stages with editable code, a working and deployed version toggle, and the destination dataset configuration.
Pipeline builder. Working v6 alongside deployed v6.
Why SQL rather than a mapping UI

Three reasons, all of them about what happens later.

It transfers

A new engineer can read a SQL stage on their first day. A proprietary mapping graph has to be learned before it can be judged, and that learning is not portable anywhere else.

This is the difference between an integration one person owns and an integration a team owns.

It diffs

Because stages are text, a change is a diff. You can see exactly what moved between the deployed version and the one waiting to go out.

Versioning a visual graph produces a picture of a change. Versioning SQL produces a review.

It survives us

If our relationship ends, you keep definitions that describe what your data means, in a language your team already reads.

Lock-in through opacity is a business model. We would rather the reason you stay is that the platform is worth paying for.

What the platform holds around the SQL

  • Declared inputs and a single output table per pipeline, so the dependency graph is real rather than implied.
  • Event-driven execution. A pipeline runs when a source it declared actually changes, not on a cron guess.
  • Pipeline variables and run context, so the same definition serves more than one customer or period without being copied.
  • Validation and data-quality checks against the prepared output, before anything downstream sees it.
  • Per-cell lineage, so a questioned number resolves back to the records and the pipeline version that produced it.

Where AI fits, and where it does not

The agent can draft a SQL pipeline from a description, and it is genuinely useful for the first eighty percent of a transformation. What it produces is a definition you read and approve, not a black box that starts running.

Nothing runs on a schedule, and nothing writes to a destination, until a person has approved it. That boundary is a product decision rather than a limitation we plan to remove.

Bring a transformation nobody can explain.

The ones held together by a spreadsheet and an institutional memory are the ones this is built for.

Talk to us