Skip to content

Rocky: the typed graph between your code and your warehouse

The typed graph between your code and whatever warehouse you have chosen. Branches, replay, column-level lineage, contracts, and per-model cost. Storage and compute stay where they are.

The failures Rocky turns into compile errors

Section titled “The failures Rocky turns into compile errors”

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.

Terminal window
curl -fsSL https://raw.githubusercontent.com/rocky-data/rocky/main/engine/install.sh | bash
rocky playground my-first-project
cd my-first-project
rocky compile # type-check
rocky test # run assertions locally
rocky run # materialize the DAG against local DuckDB

You 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.

One trace, one cost graph, one replay handle

Section titled “One trace, one cost graph, one replay handle”

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 counts

Walk 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.