State-based deployment (SSDT/DACPAC) diffs desired against actual and generates the deploy script. Nobody authored it, and a publish runs whatever the diff produced — no one has to read it first.

A rename surfaces in the diff as a destructive DROP plus ADD, so the dangerous version is the one that runs — and afterward there's no migration history of what changed or who ran it. You can't see the damage coming or trace it once it's done.

SQL Server shops run the same schema across many databases — a database per tenant, an instance per region. By hand that's the same change pasted into SSMS one database at a time; miss one or fat-finger another and they quietly diverge.

The SSDT project, dev, staging, and prod diverge the moment one change lands outside the pipeline — and the next publish generates a surprise diff against a database it no longer matches.

SQL review runs on the change before it applies — 200+ rules catch the DROP COLUMN a DACPAC diff slipped in, a destructive type change, a missing clustered index, and naming violations. The ruleset is strict on production, relaxed on dev.

The migration applies in dev, then staging, then production — and across a whole database group in one rollout, not pasted in database by database. The same script meets progressively more realistic data, so problems that only show at scale surface in staging. A failure stops the chain.

Approval gates sit between stages. Routine changes auto-promote into dev; production-bound DDL waits for a human who sees the SQL, the review results, and the rollout plan in one record.

Every applied migration is logged with version, environment, executor, and timestamp. Each entry keeps a schema snapshot, and schema sync compares any two databases and realigns them through the same pipeline.

A user with SELECT but not UNMASK probes: WHERE salary BETWEEN 99999 AND 100001 returns a masked 0, but the matching rows give the value away. Microsoft is explicit — DDM stops accidental exposure, not inference.

Before SQL Server 2022, one UNMASK grant exposed every masked column in the database. Scoped grants arrived in 2022 — only if the whole fleet is on 16.x.

db_owner and sysadmin read cleartext. The roles most likely to be over-provisioned are the ones the mask never touches.

Masks and UNMASK grants are T-SQL DDL, per database, one at a time. No request, no review, no record of who unmasked what, when.

Workspace rules, first match wins. Conditions on environment, project, database, and classification pick the algorithm — full, partial, MD5, range, custom. One rule covers on-prem SQL Server, Azure SQL, and RDS alike.

Project-level override for a single column.

Time-bound Query or Export exemptions for named users — service accounts excluded. Every grant logged. Every access logged.

Nobody mints a least-privilege login per agent before a five-minute setup. They paste the connection they have — and if it carries sysadmin or db_owner, the agent can drop any table and, on a standalone instance, run sp_configure to enable xp_cmdshell and execute OS commands. The reach isn't the database; it's the machine.

ApplicationIntent=ReadOnly looks protective, but it only steers Availability Group read routing — on a standalone database it enforces nothing. And a keyword filter that allows SELECT is bypassed by a stacked batch: SELECT 1; DROP TABLE Orders runs with no special flag.

SQL Server Audit is real and capable — but it records the server principal, and every agent shares the one MCP login. Which agent ran that DELETE, for which user, after which prompt? The audit row names the same principal every time.

The agent reads data, ingests untrusted content, and sends it back out — the lethal trifecta in one shot. A scoped credential can't stop an injection that asks for data it's allowed to read.

The agent authenticates as itself, not as a connection string. Scope follows the identity — only the projects, databases, and tables its role allows, whatever the server-level role on the login behind Bytebase.

Sensitive values are masked before they reach the model — and unlike native DDM, the mask isn't lifted by a sysadmin login or inferred through a WHERE predicate. A restricted SSN comes back as ******, so the model can't leak what it never saw.

A change doesn't run on send. It opens a Bytebase issue, where SQL review and approval apply just as for a human-authored migration.

Database governance for SQL Server.

Schema Migration

Data Masking

MCP Server

Connect SQL Server

Explore the standard for database governance

Solutions & Platform

Resources

Change Management

Access & Security

AI & Agents

Comparisons

Company

Legal