Why database changes need a review process

Most teams review their application code with care. Every change goes through a pull request, a reviewer, and a paper trail. Then someone opens a database client, pastes an ALTER TABLE straight into production, and hits enter.

The most consequential changes a company makes — the ones to the data itself — often have the least process around them. A single unreviewed statement can lock a table, drop a column the reporting pipeline still needs, or quietly change a type and corrupt a downstream job.

Vak Shipyard is built around a simple idea: a schema change should be as reviewable, approvable, and auditable as a code change.

Cowboy SQL is a liability, not a workflow

Ad-hoc SQL run by hand against production feels fast. It is also unrepeatable, unreviewed, and invisible after the fact. When something breaks, nobody can say exactly what ran, who ran it, or whether it was the cause.

Treating each change as a migration fixes that at the root. A migration targets one database, carries one or more ordered SQL statements, and exists as an artifact the team can read, discuss, and trace later — instead of a command that vanished into a terminal’s scrollback.

Review and approval before anything runs

The point of review is to catch the problem before it reaches production, not to explain it afterward. Vak Shipyard moves every migration through an explicit lifecycle — draft → pending approval → approved → applied — with rejected and failed states for the paths that do not work out.

Along the way, reviewers and threaded comments make the change a conversation. Is the new index safe on a table this size? Is the backfill nullable? Should this wait for a maintenance window? Those questions get asked and answered against the actual statements, and nothing gets applied until it is approved.

Read and write are not the same privilege

Browsing a schema and running a SELECT should never carry the risk of changing data. That is why Vak Shipyard separates read and write connections per database.

Schema pulls and the read-only Query Studio use the read connection, and only accept SELECT-style queries — so exploring your data is safe by construction. Writes happen only through an approved migration, applied over a dedicated write connection. The capability to change production is something you grant deliberately, not something everyone has by default.

See your schema, query it safely

Good change management starts with understanding what is there. Vak Shipyard includes a schema browser for tables, columns, types, indexes, and row estimates, and a “pull schema” action that syncs the current structure straight from the database.

Query Studio sits alongside it for read-only exploration, with results as a table or a MySQL \G-style vertical view. It works across PostgreSQL, MySQL, and ClickHouse, all organized as Project → Environment → Database in one tree — so production, staging, and development are always clearly separated.

Built for a whole team

Database access is a team concern, and not everyone should have the same powers. Vak Shipyard ships with admin, editor, and viewer roles managed from an in-app users console.

Viewers browse schema and run read queries. Editors create, submit, and comment on migrations. Admins approve, apply, and manage users, connections, and settings. Reviewers can be invited per migration, and notifications go out over email and Slack when a change needs attention or lands.

Every change, on the record

When a migration matters, “I think it ran last Tuesday” is not good enough. Vak Shipyard keeps a per-migration history of every state change, comment, and apply, plus a system-wide audit log that records actions across migrations, users, connections, and settings.

That record is what makes delegation safe. You can give your team real database access and still answer, at any moment, exactly who changed what — and when.

Self-host it, keep control

Schema and credentials are among the most sensitive things a company has. Vak Shipyard can be self-hosted, so your structures, connection details, and migration history stay inside your own environment. Managed deployment is available for teams that want Vak to host and maintain it, but the foundation is ownership.

A safer way to change the most important thing you have

Your database is usually the most valuable and least forgiving system you run. It deserves more than a raw SQL prompt and good intentions.

That is the point of Vak Shipyard: every change proposed as a migration, reviewed by the right people, applied through a controlled connection, and recorded for good — so changing your schema feels less like a gamble and more like shipping.