Skip to content

Database change review for engineering teams

Upcoming · Not yet deployed

Review the SQL.
Approve the exact revision.

An upcoming ticket workspace for proposed SQL, policy findings, and human review. Approve a specific revision before a separate execution step.

Discuss Schema ChangesSee the preview

Preview the planned ticket and policy workflow.

Upcoming release: the ticket and policy workspace shown here is not yet deployed.

A closer look at Schema Changes.

Planned interface · Illustrative data
Schema Changes / Review workspaceUpcoming release · Static example
CHANGE 024Awaiting review

Add a customer reference

Production · PostgreSQL · public.orders

SQL revision 3Review mode
ALTER TABLE public.orders
ADD COLUMN customer_ref TEXT;

Balanced policy

PostgreSQL
0 blocking findingsStatic checks

No blocking findings in this example. A reviewer still inspects the SQL and target.

A new edit needs a new approval.

Changing SQL or execution options returns this ticket to Draft.

  1. 1. Draft
  2. 2. Review
  3. 3. Approve
  4. 4. Execute
Illustrative PostgreSQL ticket. Checks, approval, and execution remain separate steps; available execution options vary by engine.

Why Schema Changes

A planned workflow from proposal to execution.

01

Put the change on a ticket.

Bring the target connection, SQL, reason, and execution settings into one review.

A proposal with context

02

Surface the findings.

Use policy templates or configured rules to highlight static SQL issues for reviewers.

Templates + custom policies

03

Keep approval specific.

Editing SQL or execution settings clears approval. The reviewed revision is approved before a separate execution step.

Revision-aware review

Give the reviewer the full proposal

Prepare a ticket with the target connection, editable SQL, reason, and relevant execution settings. Policy templates or configured rules surface static SQL findings beside the proposal.

Editing SQL or execution settings returns the ticket to Draft and clears its approval. A reviewer approves the current revision, then an authorized person executes it separately.

Keep engine behavior part of the decision

Static checks help the review; they do not validate the live schema or guarantee a successful change. Transaction behavior, backup options, and supported operations vary by database engine. Review those details with the target before execution.

For policy feedback in a pull request, explore the upcoming GitHub SQL Review integration.

Before you get started

A few useful answers.

Talk through your use case
Is the ticket workspace available today?

The ticket and policy workspace shown here is upcoming and not yet deployed. The page previews its planned workflow.

What happens if approved SQL changes?

Editing SQL or execution settings returns the ticket to Draft and clears approval. Approval belongs to the reviewed revision; execution is a separate action.

Do policy checks guarantee a safe migration?

No. They are static SQL checks, not live schema validation or a dry run. Database privileges and engine behavior remain authoritative. DDL may auto-commit, and transaction and backup options vary by engine.

Make the database change reviewable before it runs.

Walk through your team’s approval process with us and explore the upcoming workspace.

Discuss Schema Changes