Catch the bad migration before anyone reviews it

A review process is a huge upgrade over cowboy SQL. But reviewers are human. They approve things at 6pm on a Friday, they skim the third ALTER TABLE in a changeset, and they don’t always remember that this particular table has forty million rows and no maintenance window.

The uncomfortable truth: some of the worst migrations that reach production were reviewed and approved. The reviewer just didn’t catch it.

That’s why the newest release of Vak Shipyard adds a layer that never gets tired: pre-flight validation — automated, engine-aware checks that run against a migration’s SQL before a human ever looks at it. Alongside it ship per-project governance, scheduled applies, saved queries, and support for 22 database engines.

Validation rules: a reviewer that never skims

Every migration in Shipyard is now checked against a catalog of validation rules before it can be submitted for review. The rules parse the actual SQL and flag the patterns that cause incidents: destructive statements, risky type changes, operations that lock large tables, missing safety clauses.

Three things make this practical rather than annoying:

• Rules are engine-aware. What’s dangerous in PostgreSQL is routine in ClickHouse, and vice versa. Shipyard ships rule profiles per engine family — Postgres, MySQL, Oracle, SQL Server, ClickHouse, warehouses, Cassandra — so checks match how the database actually behaves.
• Rules are configurable. Admins toggle individual rules or whole sections on and off, and rules with thresholds accept your values. Your team decides how strict each engine’s checks should be; viewers can read the rules, so the policy is transparent to everyone.
• Rules run before review, not instead of it. The point is not to replace approvers. It’s to make sure that by the time a human reads the migration, the mechanical problems are already gone — so the reviewer can spend attention on intent.

Governance that lives with the project

Most teams have migration policy. It usually lives in a wiki nobody reads. Shipyard now makes policy part of the project itself:

• Approvers — the set of people allowed to approve migrations in this project.
• Releasers — the (possibly different) set allowed to actually apply approved migrations.
• Required approvals — demand two, three, or more distinct approvals before a change is eligible to run.
• Self-approval policy — decide whether an author may ever approve their own migration.

Separating approve from release matters more than it looks. The person who agrees a change is correct is often not the person who should decide when it hits production. Shipyard treats those as two roles, per project, and enforces both.

Apply now — or at 3am, without being awake at 3am

Approved migrations no longer have to run the moment someone clicks the button. A releaser can schedule an approved migration to auto-apply at a chosen time — the low-traffic window, the maintenance slot, the hour when the reporting jobs are idle.

The lifecycle stays fully governed: only approved migrations can be scheduled, only releasers can schedule them, and the schedule itself — who set it, for when — is recorded like every other event. Combined with per-event Slack and email notifications (on submit, approve, apply, and reviewer assignment), the team sees every step without watching a console.

One workflow across 22 engines

Shipyard started with PostgreSQL, MySQL, and ClickHouse. The new release extends the same reviewed-migration workflow across 22 engines:

• Relational — PostgreSQL, Aurora PostgreSQL, AlloyDB, MySQL, Aurora MySQL, MariaDB, TiDB, Oracle, SQL Server.
• Analytics & warehouse — ClickHouse, Snowflake, BigQuery, Redshift, Databricks, StarRocks, Elasticsearch.
• NoSQL — MongoDB, Redis, Cassandra, DocumentDB, DynamoDB, Cosmos DB.

Capabilities are honestly gated per engine — where migrations or ad-hoc queries don’t make sense for a system, Shipyard says so instead of pretending. But the organizing model is the same everywhere: Project → Environment → Database, with separate read and write connections per database.

That means the warehouse gets the same discipline as the OLTP database. The DROP COLUMN in Snowflake goes through the same propose → validate → review → approve → apply lifecycle as the one in Postgres.

The small things that keep a team moving

Two more additions worth knowing about:

• A dashboard that assigns work. Everyone signing in sees a “needs your action” feed — migrations waiting for their approval, approved changes waiting for them to release, drafts to finish, failures to fix — plus activity trends and per-database change counts. Nothing sits in a queue because nobody knew it was theirs.
• Saved & shared queries. Query Studio queries can be saved with names, tags, and descriptions, and shared with the team via links. The SELECT that answers “how many orders are stuck?” stops living in one engineer’s terminal history.

Defense in depth, not paperwork

Each layer catches what the previous one misses. Validation rules catch the mechanical mistakes. Reviewers catch the wrong intent. Approval counts and self-approval policy catch the rushed Friday merge. Releasers and scheduling catch the right-change-wrong-time problem. And the audit log remembers all of it — with actor and timestamp — when someone asks what happened.

None of it slows down the change that deserves to ship. All of it slows down the one that doesn’t.