Typed compiler, not a templating engine
Rocky infers column types across the whole dependency graph. 35+ diagnostic codes name the problem and suggest a fix, so E013 blocks the PR before a row is written.
The expensive failures on a data platform are trust failures, not slow queries. A column type changes upstream and a revenue dashboard quietly diverges for three days. Warehouse spend doubles and nobody can say which model caused it.
Rocky moves correctness into the compiler. Each of those becomes something you catch before a row is written. See the full list, and how Rocky catches each one.
Typed compiler, not a templating engine
Rocky infers column types across the whole dependency graph. 35+ diagnostic codes name the problem and suggest a fix, so E013 blocks the PR before a row is written.
Column-level lineage at compile time
Rocky traces every column through every transformation, before anything runs. rocky lineage-diff main lists the per-column downstream blast radius for PR review.
Branches + content-addressed run records
A named branch is an isolated schema. rocky replay <run_id> inspects a run and shows its recorded per-model SQL hashes, row counts, and bytes.
Per-model cost attribution
Cost is a column on every run, not a dashboard you check afterwards. [budget] blocks fail the run on overspend, and rocky preview cost projects spend at PR time.
AI gated through the compiler
Every AI suggestion has to type-check before it lands. rocky ai generates a model, compiles it, auto-fixes what it can, and ships.
Dialect-divergence lint
P001 catches a Snowflake-only construct in a Databricks project, and the reverse. Cross-warehouse teams stop finding portability bugs in prod.
Declarative tests, not templated SQL
Tests are declarative TOML. Rocky generates the assertion SQL for your target dialect, and rocky test runs fixture-driven tests locally on DuckDB.
A tested exit door, not a one-way door
rocky emit-sql renders the compiled SQL for your transformation models with no warehouse connection. The output is plain runnable SQL, so adopting Rocky never locks you in.
curl -fsSL https://raw.githubusercontent.com/rocky-data/rocky/main/engine/install.sh | bashrocky playground my-first-projectcd my-first-projectrocky compile # type-checkrocky test # run assertions locallyrocky run # materialize the DAG against local DuckDBYou need no credentials. The playground runs on DuckDB and seeds itself on the first run.
rocky run is the one-step path for local iteration and automation. For
production or a PR-gated deploy, split it in two: rocky plan writes an
auditable plan to .rocky/plans/<id>.json, and rocky apply <plan-id> executes
it.
rocky run writes a single RunRecord to the state store. Three read commands
project that one record from different angles.
rocky run │ writes ▼ ┌───────────────────┐ │ RunRecord │ one record, in the state store └─────────┬─────────┘ │ read by ┌───────────────┼───────────────┐ ▼ ▼ ▼ rocky trace rocky cost rocky replay causality and per-model recorded hashes concurrency warehouse spend and row countsWalk through it end to end in POC #17 (trace + cost + replay against the same run_id).
Rocky is built first for data platform engineers running production-critical, multi-tenant pipelines on Databricks, where a silent failure costs real money. That is where Rocky has the most production mileage.
The next ring out: Snowflake and BigQuery shops evaluating SQLMesh, who want correctness moved into the compiler rather than the planner, and who prefer SQL by default. Those adapters are Beta today. See the Roadmap.