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, events
- 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
- 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 OndatraSQL has six 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.
How OndatraSQL validates data at three stages and why each stage exists.
Why transport logic lives in lib/ as Starlark functions, separate from SQL models.