Governed schema work

Review schema changes before operational rollout

Stage DDL and data mutations, review the generated SQL, and apply changes only after a responsible person confirms the target, statement, and consequences.

Changes: DDL + DML
Review: Before apply
Preview: SQL + mongosh
Safety: Transaction aware

Schema changes are the highest-stakes operations most teams run against production databases. A bad ALTER TABLE can lock a table for minutes, a misapplied migration can drop columns that downstream services depend on, and an index creation on a large table can saturate I/O during peak hours. Yet many teams still apply these changes by pasting SQL into a terminal and hoping the right person checked it first.

SyneHQ makes the entire review visible. Every schema change starts as a proposal, gets a generated SQL preview, passes through a named reviewer, and only runs after explicit approval. The person who wrote the DDL is not the same person who applies it, and the review record stays with the change long after it has run.

Stage it, review it, then apply it

A schema change in SyneHQ follows a change ticket workflow: propose the change, review the generated SQL, approve or reject it, and apply it only after approval.

The change ticket captures what is being changed, who requested it, which connection it targets, and the exact SQL that will execute. The ticket moves through a visible pipeline: Draft, Review, Approved, and Applied. At each stage, the responsible person and the current state are clear.

This is not a deployment pipeline or a CI/CD gate. It is a review surface built into the data workspace so that a team lead or DBA can see the SQL, confirm the target database, and make an informed decision before anything runs. The generated command is visible and editable in the review step, so a reviewer can catch a missing WHERE clause, an unintended CASCADE, or a table name that does not match the intended environment.

When Kole, the AI agent, proposes a schema change as part of an investigation, the same review gate applies. Kole's proposed DDL enters the ticket workflow and waits for human approval before execution. Automatic discovery is automatic; execution never is.

Change ticket workflow

Change #142 — Add renewal_date to contracts

DraftSQL proposed

ReviewAwaiting approval

ApprovedReady to apply

AppliedMigration complete

change-142.sqlReview required

ALTER TABLE contracts
  ADD COLUMN renewal_date date;

-- Target: production.public.contracts
-- Requested by: Revenue Ops (j.martinez)
-- Reviewer: d.chen (DBA)

Migration safety with full SQL preview

Before a migration runs, SyneHQ generates a full preview of the SQL that will execute. The preview includes every statement in the migration: ALTER TABLE, CREATE INDEX, ADD COLUMN, DROP CONSTRAINT, and any DML that accompanies the structural change.

Alongside the SQL preview, the review surface shows a safety summary: whether the migration will run inside a transaction, whether rollback is supported for the target engine, the database engine type, and an estimate of the rows affected. This context helps a reviewer decide whether the migration is safe to run during business hours or should be scheduled for a maintenance window.

Transaction awareness matters because not every engine handles DDL the same way. PostgreSQL wraps most DDL in transactions and supports rollback. MySQL auto-commits DDL statements and cannot roll them back. MongoDB has no DDL transactions in the traditional sense. The safety summary makes the engine behavior explicit so the reviewer does not have to remember it.

Rollback considerations are surfaced before the migration runs, not after it fails. If the engine does not support transactional DDL, the review surface says so. If a migration includes both reversible and irreversible steps, the preview distinguishes them. The goal is to move the risk assessment from the reviewer's memory to the review interface.

Migration preview

Full SQL preview with safety assessment

migration-047.sql

-- Step 1: Add column
ALTER TABLE contracts
  ADD COLUMN renewal_date date;

-- Step 2: Backfill from legacy field
UPDATE contracts
  SET renewal_date = end_date + INTERVAL '30 days'
  WHERE renewal_date IS NULL;

-- Step 3: Create index concurrently
CREATE INDEX CONCURRENTLY
  idx_contracts_renewal
  ON contracts (renewal_date);

Safety assessment

TransactionYes

RollbackSupported

EnginePostgreSQL

Est. rows1.2M

Locks tableNo (concurrent)

Auto-commit DDLNo

Migration steps

ALTER TABLE — reversible

UPDATE — in transaction

CREATE INDEX — concurrent

$synehq migrate apply --ticket MIG-047

Running step 1/3 ... ALTER TABLE ✓

Running step 2/3 ... UPDATE 1,247,382 rows ✓

Running step 3/3 ... CREATE INDEX CONCURRENTLY ✓

Migration completed in 3.2s — 0 errors

Changes teams review every sprint

Schema changes are not a rare event. Most teams encounter several categories of DDL and DML changes in every sprint, and each one benefits from a visible review step.

Adding columns and altering types

Adding a renewal_date column to a contracts table, changing a status field from VARCHAR to an ENUM, or widening a numeric column to support larger values. Each of these changes the table structure that downstream queries, reports, and application code depend on. The review step confirms the column name, type, default value, and nullability before the ALTER runs.

Index creation and modification

Creating an index on a high-traffic table can lock reads or saturate disk I/O depending on the engine and table size. The SQL preview shows the exact CREATE INDEX statement, and the safety summary estimates the row count so the reviewer can judge timing. Dropping an unused index is equally reviewable: the generated DDL is visible, and the reviewer confirms the index name and table before it disappears.

Data backfills and bulk updates

Backfilling a new column with computed values, updating a status field across thousands of rows, or migrating data from one table to another. These DML operations are not schema changes in the strict sense, but they follow the same review workflow: the SQL is generated, previewed, and approved before execution. Transaction awareness tells the reviewer whether a failed backfill will leave partial results.

Permission and constraint changes

Granting a role access to a schema, adding a foreign key constraint, or modifying a CHECK constraint. These changes affect who can access what and how the database enforces data integrity. The review step makes the exact GRANT, ALTER, or ADD CONSTRAINT statement visible so the reviewer can confirm the scope.

Scheduled and recurring migrations

Some migrations run on a schedule: weekly partition creation, monthly archival moves, or periodic index rebuilds. SyneHQ's review workflow applies to scheduled changes the same way it applies to ad hoc ones. The SQL is generated and reviewed before the schedule activates, and each execution is logged.

Start reviewing your schema changes

SyneHQ brings schema change review into the same workspace where your team browses data, runs queries, and builds reports. The review is not a separate tool or a bolt-on approval system. It is part of how changes move from proposal to production.

Data Explorer is where schema changes are staged, previewed, and applied after review.
Quantum Lab keeps investigation notebooks where Kole's proposed changes enter the review workflow.
Dashboards surfaces the state of pending and completed changes for team visibility.
Kole proposes schema changes as part of AI-driven investigations, always gated by human approval.

Start with the change your team needs to make this week. Stage it, review the SQL, and apply it with confidence.