DeltaScope helps teams catch dangerous DDL and DML before changes reach a database. Use the same offline-first audit engine in migration review, CI pipelines, HTTP services, and AI-assisted SQL workflows.
$ curl -fsSL https://raw.githubusercontent.com/Fanduzi/DeltaScope/main/install.sh | sh
Why DeltaScope
DeltaScope gives DBAs, application engineers, CI systems, and AI agents one consistent way to review DDL and DML before rollout. The goal is simple: catch risky changes early, keep policy consistent, and avoid discovering preventable issues after a migration or script has already run.
Catch risky DDL such as destructive ALTER TABLE operations, missing comments, or policy violations before migration tools ever touch the database.
Use the same audit logic in local review and CI so developers do not get one answer locally and a different answer in automation.
CLI, HTTP, MCP, and Go library integrations all return the same underlying findings, verdicts, and rule identifiers.
Core Workflows
DeltaScope is most useful at the moments when teams make high-impact DDL and DML decisions: before merging migrations, inside CI, and inside agent-driven coding loops.
Audit migration files before they are applied so destructive changes, missing governance details, and schema policy violations are caught while they are still cheap to fix.
Read migration workflowBlock merges or deployments when statements cross your configured threshold. This works well for teams that want dangerous DELETE and UPDATE patterns stopped automatically.
Read CI workflowGive agents a stable JSON contract, stable rule IDs, and explicit verdicts so they can revise unsafe SQL without scraping prose or guessing what failed.
Read AI agent workflowHow It Works
DeltaScope is offline-first by default. You can audit DDL and DML with no database connection, then optionally add live metadata when your workflow needs instance-aware checks.
What You Get
DeltaScope covers both governance and automation: safe local review for humans, stable structured output for machines, and one engine that stays consistent across delivery surfaces.
Audit both schema changes and data-changing statements instead of stitching together separate tools for separate risk categories.
Return verdicts, findings, and rule IDs in a predictable structure that CI systems and AI agents can rely on.
Change enforcement without changing code. Teams can start with blockers only, then tighten to warnings as confidence grows.
Use the same audit behavior from the CLI, inside services, through MCP tooling, or by embedding the Go library directly.
Stay offline when you want portability and safety. Add instance-aware checks only when your workflow needs real schema context.
Readable output for engineers, structured output for automation, and stable contracts for agentic review loops.
Verdict Model
Every finding maps to a severity. Every audit request maps to a verdict. You can keep the same model across local review, CI, services, and AI workflows.
| Verdict | Condition | Exit Code (CLI) |
|---|---|---|
| reject | ≥ 1 blocker finding | 1 (when --fail-on blocker) |
| review | No blockers, ≥ 1 warning or notice | 1 (when --fail-on warning) |
| pass | No findings at any level | 0 |
Rule Catalog
Stable dotted rule IDs let teams inspect, tune, and discuss the same checks across CLI, CI, services, and agent workflows.
| Rule ID | Area | Default Level | Description |
|---|---|---|---|
dml.where.require |
DML | blocker | DELETE or UPDATE must include a WHERE clause |
dml.limit.forbid |
DML | warning | UPDATE and DELETE statements must not include LIMIT |
dml.subquery.forbid |
DML | blocker | UPDATE and DELETE statements must not include subqueries |
ddl.column.comment.require |
DDL | warning | Columns must have a comment |
ddl.table.comment.require |
DDL | warning | Tables must have a comment |
ddl.alter.drop_column.forbid |
DDL | warning | ALTER TABLE drop column is forbidden |
ddl.alter.merge.mysql.require |
DDL | warning | Multiple ALTER TABLE statements on the same table should be merged |
ddl.index.key_length.max_bytes.require |
DDL | blocker | Index key length must stay within InnoDB instance limits |
# View all rules
$ deltascope rules list
# Show detail for one rule
$ deltascope rules show dml.where.require
# Audit with custom policy
$ deltascope audit --file ./migrations.sql --config ./strict-policy.yaml
Integrations
Product surfaces matter, but they matter more after the homepage has already earned trust. DeltaScope keeps them aligned so teams do not have to duplicate DDL and DML review logic.
Fast local review for developers, scripts, and migration checks.
Expose the same audit engine as a service for internal tooling and platform workflows.
Plug DDL and DML review into Claude Code, Codex, Cursor, and other agent-driven environments.
Embed DeltaScope directly inside Go services that need deterministic DDL and DML audit behavior.
Usage Examples
Three distinct examples: one for unsafe DML, one for migration DDL, and one for machine-readable CI output.
# ── DML: reject an unsafe DELETE ──
$ deltascope audit --sql "delete from users"
Verdict: reject
Statements: 1
Blockers: 1 Warnings: 0 Notices: 0
Statement 1: DELETE
[blocker] dml.where.require: DELETE or UPDATE must include a WHERE clause
# ── DDL: review a migration before rollout ──
$ deltascope audit --file "./migrations/20260322.sql"
Verdict: review
Statements: 1
Blockers: 0 Warnings: 1 Notices: 0
Statement 1: CREATE TABLE
[warning] ddl.column.comment.require: column `id` must have a comment
# ── CI / JSON output ──
$ deltascope audit \
--sql "alter table users drop column age" \
--format json \
--fail-on warning
{
"verdict": "review",
"summary": { "blockers": 0, "warnings": 1, "notices": 0 },
"statements": [ ... ]
}
Trust Signals
DeltaScope is open source, ships published releases, documents its contracts, and keeps one audit path across human and machine workflows. Those are stronger trust signals than broad promises.
Core concepts, recipes, and references are published for teams that need implementation depth after the homepage overview.
Findings are grounded in stable dotted identifiers so humans and automation can speak about the same rule consistently.
Installers, release artifacts, and release notes are already part of the product story, which matters for adoption and automation.
Teams can adopt the tool without granting database access to every local, CI, or agent execution environment.
Releases
Recent releases show the product getting more usable in real delivery paths: CI integration, HTTP readiness, MCP tooling, and a more complete audit contract.
Install once, audit locally, gate in CI, and reuse the same policy everywhere.