Why Interlace
An honest comparison
Every tool here is good at what it was built for. This is where Interlace differs, and where it does not.
| Capability | Interlace | dbt | SQLMesh | Airflow |
|---|---|---|---|---|
| SQL models | Yes | Yes | Yes | No — orchestration only |
| Python models in the same DAG | Yes — interchangeable with SQL, either direction | Partial — platform-dependent, not freely mixable | Partial — supported, SQL-first | N/A |
| Plan / apply with change classification | Yes — column-pruned reuse | No | Yes — the original of this idea | No |
| Built-in scheduling | Yes — cron and interval | No — needs an orchestrator | Partial | Yes — its core strength |
| Streaming ingestion not what these three are for — compared properly below | Yes — durable log, exactly-once into the warehouse | No | No | No — can trigger a loader |
| Execution engines which backends transforms can run on | Comparable — DuckDB/DuckLake, MotherDuck, quack, Postgres, Redshift, Snowflake, BigQuery and Spark, with near-full strategy support on each. Databricks is not built | Very broad — plus a long tail of community adapters | Broad | N/A |
| How proven those engines are the honest gap | Thin — only the DuckDB family and Postgres are tested in CI. Spark is beta against a local session; the four cloud warehouses are alpha — dialect-correct and unit-tested for SQL shape, but not yet run against a live account | Years of production use | Established | Years of production use |
| Read and write external systems sources and reverse-ETL targets | Broad — Postgres, MySQL and SQLite over DuckDB ATTACH; Parquet, CSV, JSON and S3; Iceberg and Delta reads | Via the warehouse | Via the warehouse | Very broad — operator ecosystem |
| Community and ecosystem | Small | Very large | Growing | Very large |
Three things to know before you commit
Attached tables are not models
You can read an attached Postgres, MySQL or SQLite table from any SQL model. Interlace does not track it, though: it never appears in lineage, and changing it will not make anything rebuild. Only models get fingerprints — an attached table is just a place to read from.
One machine
Interlace runs as a single process, with its control plane in SQLite on local disk. There is no multi-node coordination and no leader election. Scaling out is designed but not built, so today the ceiling is the machine you run it on.
Help us prove the new engines
The Spark engine is beta and the cloud adapters — MotherDuck, Redshift, Snowflake, BigQuery — are alpha: dialect-correct, but not yet run against a live account. If you have one, point Interlace at it and tell us what breaks.
Where the others are stronger
- dbt
- An adapter for every warehouse and years of production mileage on all of them, plus an ecosystem no new tool will match for a long time.
- SQLMesh
- Originated plan/apply, virtual environments and the interval ledger. Interlace adopted all three, and SQLMesh remains the deeper SQL-first tool.
- Airflow
- Cross-system orchestration that reaches well outside the data platform. Interlace schedules its own models and nothing else.
- Dagster
- Software-defined assets with a richer typing and resource model. If you want one orchestrator spanning many teams and tools, it goes further.
- dlt
- Complementary rather than competing — its schema inference and connectors are excellent, and you can call it inside a Python model.
- Snowflake, BigQuery
- Not competitors at all. They are execution engines Interlace runs models on.
Interlace is for teams who want transformation, orchestration and ingestion to be one deployable thing, on a warehouse that fits on one machine.
Ingestion
A different set of alternatives
dbt, SQLMesh and Airflow do not ingest events, so scoring them on it proves nothing. The honest comparison for durable ingestion is the platform Interlace's own architecture doc names as the reference.
| Question | Interlace streams | Cloudflare Data Platform |
|---|---|---|
| How events arrive | POST to the daemon you are already running for the API and scheduler | HTTP endpoint or a Worker, accepted at the edge |
| What the 200 means | Fsynced. The log runs synchronous=FULL, so the write survives power loss | Accepted for exactly-once delivery downstream |
| Where events land | A table in your own warehouse, which models read like any other | Iceberg tables or Parquet and JSON files in R2 |
| What transforms them | The full model DAG — SQL and Python, after the flush | SQL in-stream, then anything that can read Iceberg |
| Who operates it | You. One process, one machine | Cloudflare. Managed, and distributed across their network |
| Where it can run | Anywhere. MIT-licensed, no hosted dependency | On Cloudflare |
Cloudflare is the more capable ingestion platform, and it is not close: a managed, globally distributed pipeline with petabyte-scale query on top. Interlace is a single process with a write-ahead log. What it buys you is that the events land in the same graph as your models — one fingerprinted DAG, one plan, one deployable thing — instead of a second system to run and a handoff to get wrong. If you are already on Cloudflare and want managed ingestion at the edge, use theirs. Interlace can read the Iceberg tables it produces.
Cloudflare capabilities per their Pipelines and R2 Data Catalog documentation.
Multi-Engine
One codebase, named engines
Models run on named engines and pin to one with engine:. Beyond those, attach: mounts external databases onto the warehouse — readable in any SQL model
and writable through export sinks.
DuckDB + DuckLake
Stable. Default engine and storage: Parquet with a SQL catalog
Postgres
Stable. Strategies execute inside Postgres over ADBC
quack
Stable. A warehouse served over the quack protocol, shared between processes
Spark
Beta. SQL runs in Spark, Arrow both ways; needs a Delta or Iceberg catalog
Snowflake · BigQuery
Alpha. Full strategy set over ADBC, including scd
Redshift · MotherDuck
Alpha. Redshift reuses the Postgres wire; MotherDuck is cloud DuckDB
Separately from engines, attach: mounts Postgres, MySQL or SQLite onto the warehouse
to read from or deliver into. An attached table is not a model, so it never appears in lineage and
changing it rebuilds nothing.
Ready to simplify your data pipelines?
Get started with Interlace in minutes. Install, define your first model, and run.