Rocky: the typed graph between your code and your warehouse

Checks Rocky reports at compile time

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 reports supported static problems before execution. The available SQL, schemas, and configuration determine which checks can run. A clean compile does not prove general SQL validity or correct result values. See the full list, and how Rocky catches each one.

Typed compiler, not a templating engine

Rocky infers types where source and expression information is available. Its diagnostics name problems and suggest fixes. An E013 error fails that compile.

Column-level lineage at compile time

Rocky traces represented columns through supported transformations. rocky lineage-diff main lists the recorded downstream impact 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

Rocky records available run duration and byte metrics. rocky cost derives a per-model allocation from metrics plus configured rates or an adapter formula. An estimate or allocation is not a warehouse bill.

AI-assisted drafting

rocky ai generates a draft and validates it against available project context. Review the generated files and run relevant checks. Replication pipelines can use the saved plan and approval path before execution.

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.

Data products declared in a spec file

products/<name>.toml states a product’s grain, columns, checks, and freshness. rocky product compile renders the model’s contract and merges spec-owned sidecar metadata, turning the grain and checks into declarative [[tests]]. rocky fulfill drives an agent through drafting and verification (experimental). Its output checks follow apply, so a failure can be live.

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.

Get Started in 60 Seconds

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

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     cost allocation and row counts

Walk through it end to end in POC #17 (trace + cost + replay against the same run_id).

Who Rocky is for

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.

Import an existing projectRun rocky import-dbt against a dbt Core project. You get a Rocky repo on disk, and you can move over one piece at a time.

Using Dagster?dagster-rocky wraps the CLI as a ConfigurableResource: auto-discovery, asset checks, and Pipes through one subprocess hop.

Declare a data productWrite the spec, lower it onto the model's contract and sidecar, and approve a revision. rocky fulfill drives the agent loop between those steps.