Every change starts with a proposal.
Stage schema work and data mutations with the requester, target connection, and exact SQL on the ticket.
Governed schema work
Propose the change. Review every detail.
Stage DDL and data mutations, review the generated SQL, and apply changes only after a responsible person confirms the target, statement, and consequences.
See the data changes workflowReview state · sample
Pending
Data Changes workspaceSample dataAdd a renewal date
CHG-024 · Proposed change
ALTER TABLE contracts
ADD COLUMN renewal_date date;
-- Review target and rollback firstproduction.contractsSource in context
Ask with Kole
Which database will this change touch?
Human review before execution
One platform, a connected workflow
Built for the way your team works.
Keep the proposal, SQL, and review decision together before rollout.
Schema Changes
An upcoming ticket workspace for proposed SQL, policy findings, and human review. Approve a specific revision before a separate execution step.
Explore Schema ChangesApproval Workflow
When Kole proposes a consequential action, inspect the operation, adjust its arguments, and approve or reject it before execution continues.
Explore Approval WorkflowData Tools
Move databases, schedule backups, build pipelines, and send recurring query results to your team. Manage the source, destination, and run history in one place.
Explore Data ToolsMade for data changes
The details that make work repeatable.
From the first question to the next review, keep the source, the method, and the decisions connected.
“Which database will this touch?”
“What SQL will execute?”
“Can this change be rolled back?”
Bring migration context into view.
Inspect the statement alongside the target engine, transaction behavior, and rollback considerations.
Keep approval separate from execution.
A responsible person confirms the proposal before it runs. Kole’s consequential proposals follow the same review gate.
Review the complete statement
Inspect the generated DDL or DML, target connection, and scope. Check column definitions, constraints, and WHERE clauses before the change moves toward execution.
Account for the database engine
Review transaction behavior and rollback considerations for the target engine. A PostgreSQL migration and a MySQL DDL change do not have the same recovery properties.
Keep a named decision on the ticket
Track the requester, reviewer, and state from draft through review and application. A proposal from Kole follows the same human approval requirement.
Human review, built in
Your team stays in control.
Keep the target, proposed operation, and review decision in view. Kole helps investigate and propose the work; your team approves configured consequential actions.
A clear approval gate
Inspect the statement and arguments. Approve, edit, or reject the proposal before execution.
A defined workspace
Keep connections and saved work within the team context and permissions that govern access.
CHG-024 · Sample ticket
Add a renewal date
ALTER TABLE contracts
ADD COLUMN renewal_date date;
ADD COLUMN renewal_date date;
ConnectionProduction · PostgreSQL
ReviewerJamie Chen
Awaiting human approval
Connected to your work
Start with the data you already have.
Explore connected databases and files, inspect the schema, and carry the source context into your analysis. Your question can span more than one system.
- Browse records and relationships with Data Explorer before choosing the query.
- Use Tangents for supported federated queries across databases and files.
The workflow in practice
Review schema changes before operational rollout.
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.
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.
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.
Resources
Take the next question further.
Practical guides, reusable starting points, and product details.
Customer perspective
More time for the work that matters.
With their robust platform, we've seamlessly integrated multiple data sources, unified analytics, and automated standard reporting, saving us countless hours each week.