What Beetl is
The mental model in one page — and what Beetl is not.
Beetl is a programmable data integration platform. It connects the business systems you already run, transforms what comes out of them with SQL, and makes the validated result queryable, chartable, and reachable from your own tools.
The short version: custom integrations without custom infrastructure.
The rest of this page is the mental model. Five nouns, in the order data moves through them, plus the three things that consume the output.
The path data takes
Connection ──▶ Dataset ──▶ Pipeline ──▶ Dataset ──▶ Query result
(link to a (Bronze) (SQL stages) (Gold) (durable, addressable)
system) │
▼
chat · dashboards · MCPEvery arrow is a thing you configure once. Nothing in that chain is magic, and every step is inspectable after the fact.
Connections bring data in
A Connection is a link to one source system. There are seven system types today: PostgreSQL, Webhook, HTTP Feed, File upload, Microsoft Dynamics 365 Business Central, SAP Business One, and Server-Sent Events.
Two of those are push. You get a bearer token and an endpoint, and the source system posts to it.
The rest are pull, and pull needs a beetl-connector running inside your network. That binary
ships as a Docker image, holds the credentials for the local system, discovers its schema, and
sends extracted batches out to Beetl. It reads. It has no path to write back.
Datasets are where data lands
A Dataset is a Delta Lake table. It lives in object storage that you register and own, under
{tenant_id}/{tier}/{data_set_id}/v{version}. Delta gives it ACID writes, versioning, and time
travel, and Beetl compacts and vacuums it on its own schedule.
Datasets carry a tier: Bronze, Silver, or Gold. Bronze is what arrived, Gold is what you would hand to someone. That ordering is a naming convention the team agrees on, not a rule the platform enforces. There is no tier lineage DAG, and nothing stops a Gold table reading from another Gold table.
Schema is enforced on the way in. A second ingest whose Arrow schema disagrees with the existing dataset is rejected rather than silently coerced.
Pipelines transform
A Pipeline is a notebook. You pick source datasets, write SQL stages against them, preview any stage on real rows, and optionally point the last stage at a destination dataset. A pipeline with no destination is a legitimate thing to build, and it is how most exploration starts.
Pipelines have two versions at all times. Working is your editable draft. Deployed is the version that actually runs. Save writes the draft. Deploy promotes it. They are deliberately separate, so an unfinished edit cannot execute against production data.
You query the result
The Query page is a multi-tab SQL editor over DataFusion, using the PostgreSQL dialect. It autocompletes columns from the real schema, cancels a long run, and charts what comes back.
Click any cell and Beetl shows you the column's role, the SQL expression behind it, and which relations it came from. Where it can build a deterministic path back to the contributing rows, it offers to drill into them, which produces another addressable result.
Results are artifacts, not screen state. Each one has a URL. Each one expires after seven days. See Query results before you build a habit around them.
Three things consume the output
Chat is the first. The assistant is a sidebar on every page and a full-screen surface of its own. It lists datasets, runs queries, and builds pipelines through a fixed set of tools, and since August 2026 it edits the page you are looking at directly on four surfaces.
Dashboards are the second. Beetl embeds Apache Superset, which reads tenant data over a read-only Arrow Flight SQL interface scoped by credential. This is the only saved, shareable visual surface in the product, and the dashboards themselves are authored in Superset.
MCP is the third and the one nobody guesses. Beetl exposes 13 tools over a Streamable-HTTP
JSON-RPC endpoint, authenticated with a per-user API key scoped read or write. Claude, Cursor,
or your own code get the same tool surface the in-product assistant uses.
Automations run it on a clock
An Automation is a recurring investigation described in plain language. It runs on a cron schedule, queries read-only, and returns a Markdown report plus every query it ran and why. It is observe-only by construction: it can propose nothing and change nothing.
What Beetl is not
Not a dashboard builder. Dashboards are authored in Superset and embedded. There is no in-product chart designer, and an ad-hoc chart you build on a query result is not saved anywhere.
Not an alerting system. There is no outbound notification path in the server today. No email, no Slack, no webhook. An Automation that finds a problem tells you by being red the next time you open Beetl.
Not a warehouse you buy from us. You register your own object store, and your data sits in your bucket. That is also the data-residency answer for a buyer who needs one.
Not something that writes to your source systems. Extraction is one-directional. What Beetl writes, it writes to its own datasets. See The agent trust boundary for where the exceptions are and how they are gated.
Not a replacement for SQL. SQL is the transformation language. The assistant writes it, edits it, and explains it, and you still read what it wrote before you deploy.
Not a team product yet. Query results, chat sessions, and API keys are scoped to the person who created them. Automations are the one workspace-owned object. There is no sharing, no commenting, and no shareable link to a result.