Modeled in dbt, used across systems.

dbt is where your models, their dependencies and their tests live. ActQL takes the data those models produce to the systems the warehouse cannot reach—a CRM, a support desk, a spreadsheet—and brings their data back to the models. The two fit together in two directions.

Use the models dbt built

Say dbt builds usage_30d in Snowflake: one row per account, with its active users and the trend. In ActQL that model is a table like any other, so one program joins it with Salesforce accounts and acts on the result:

SELECT a.id, a.name, u.active_users, u.trend
FROM salesforce.accounts AS a
JOIN snowflake.usage_30d AS u ON a.id = u.account_id
WHERE u.active_users < 5 AND u.trend = 'down';

Run it from the CLI and you get a table. Add |> EFFECT UPDATE salesforce.Account … and the same program writes a field back, pausing at a Checkpoint that shows the records and values about to change; add |> INFER when a judgment is needed. Any scale on the top page shows how the engine plans this very JOIN.

This direction needs no adapter: ActQL reads the warehouse the models live in through its Connector, and the join is pushed down to Snowflake where it can be.

Run dbt models through ActQL

Keep the usual dbt workflow—models, ref(), source(), tests, materializations, incremental—and make ActQL the execution backend, so a model can read across systems: a staging model over Salesforce, a mart that joins the warehouse with a SaaS API. dbt-actql itself holds no knowledge of Salesforce or Postgres; that belongs to ActQL's Connectors and planner, so adding Connectors does not make the adapter more complex. An adapter is not the same as official support on dbt Platform.

What runs today: compiled dbt SQL is accepted by ActQL unchanged when the project turns dbt's quoting off and a model is a SELECT, or a Pipe query over materialized ref()s. Pipe queries over ephemeral models, double-quoted identifiers and INFER inside a model are not accepted yet.

Keep builds and actions apart

A model is rebuilt whenever dbt build runs; an action to the outside should not be. Keep external writes—a CRM update, an email—in an ActQL program with its own trigger and approval, reading the finished models, rather than inside a model. Rebuilding then never resends anything.

How is this different from dbt?

It is not a replacement. dbt transforms data inside one warehouse and keeps the models honest; ActQL reads and writes across systems, treats every external write as a checkable, approvable Effect, and recovers a Run that stopped halfway. Where a job ends at the warehouse, dbt alone is enough.

dbt
 ↓
dbt-actql
 ↓
ADBC
 ↓
Flight SQL
 ↓
SQL
 ↓
ActQL
 ↓
cross-system physical execution

Coming soon.