OndatraSQL
Concepts
On this page
How OndatraSQL works.
- Models: every model is a SQL file that produces one table
- Model Kinds: table, append, merge, tracked, scd2
- Lib Functions: API dict for inbound fetch and outbound push
- Change Detection: process only changed data via DuckLake snapshots
- Incremental Models: cursor-based loading for SQL and lib functions
- Schema Evolution: additive and destructive changes without migration
- Dependency Graph: automatic execution order from SQL references
- Outbound Sync: why commit-first and at-least-once delivery
- State: the push queue, fetch staging, and OAuth tokens — separate from DuckLake
- Validation: constraints, audits, and warnings at three stages
A model is a SQL file that produces one table. The file path is the table name, directives control behavior, and lib functions handle API data.
Why transport logic lives in lib/ as Starlark functions, separate from SQL models.
Why OndatraSQL has five model kinds and when to choose each one.
How OndatraSQL uses DuckLake snapshots to process only changed data. AST-level query rewriting, join handling, and skip detection.
How OndatraSQL handles schema changes automatically when your model SQL changes.
Why OndatraSQL uses cursor-based incrementality, how it interacts with CDC, and what the tradeoffs are.
How OndatraSQL builds and executes the dependency graph automatically from your SQL.
Why OndatraSQL validates data at three stages and why each stage exists.
Why OndatraSQL commits data before pushing to external systems, and what that means for your push function.
How OndatraSQL stores operational state — the push queue, fetch staging buffer, and OAuth refresh tokens — separately from your DuckLake data.