SDB501[high]Data-dependent

Unique constraint added to existing data

Adding UNIQUE can fail on duplicates and builds its index under a lock.

Why it's risky in PostgreSQL

If any duplicates exist the migration fails in production even though it passed on an empty database. The index build also blocks writes.

What triggers it, and the safer way

unsafe.sql

ALTER TABLE users ADD CONSTRAINT users_email_key UNIQUE (email);

safer.sql

-- check for duplicates first; build the index without blocking writes:
-- shadowdb:allow SDB501 duplicates checked on production 2026-10-01
CREATE UNIQUE INDEX CONCURRENTLY users_email_key ON users (email);

Suppress it when you're sure

Put this comment on the line before the statement. The reason is required and shows in the report.

suppression

-- shadowdb:allow SDB501 <why this is safe here>

Applies to PostgreSQL 14, 15, 16, 17.