Shipyard

Data teams review SQL, not results

Application teams get a preview environment on every pull request. Data teams get a shared staging warehouse, a queue for it, and a review process where someone reads 200 lines of SQL and approves based on vibes.

Shipyard closes that gap.

What happens on a pull request

1. Shipyard builds an isolated warehouse from a stratified sample of production — small enough to be cheap, representative enough to be meaningful.
2. Your models run against it.
3. The PR gets a comment showing the data diff: row count deltas, distribution shifts, new and dropped columns, and any downstream model whose output changed.
4. The environment is destroyed on merge.

Why sampling, not cloning

A full clone of a production warehouse is expensive enough that teams run one shared staging environment, which reintroduces the queue. Shipyard samples with stratification on the columns you declare as significant, so rare categories survive the sample rather than being rounded away.

Cost

The sample is typically 0.5–2% of production volume. For most teams a preview environment costs cents, which is what makes per-PR isolation viable at all.

Warehouses

Snowflake, BigQuery, Databricks and Postgres. dbt and SQLMesh projects work without modification.