Suppression list lookup is indexed for O(1) performance

Every email dispatch that uses a local suppression table performs a lookup against that table before sending. Without an index on the email column, this lookup is a sequential full-table scan. At 100,000 suppressed addresses, a sequential scan takes tens of milliseconds. At 1,000,000 entries — common for mature lists — it degrades to hundreds of milliseconds per lookup, making pre-send verification the bottleneck in campaign throughput. Bulk campaigns that send to 50,000 contacts perform 50,000 suppression lookups; at 200ms each, that is 2.8 hours of scan time before a single email is dispatched.

Add a unique constraint (which PostgreSQL implements as a unique index) on the email column of the suppressions table:

ALTER TABLE suppressions ADD CONSTRAINT suppressions_email_unique UNIQUE (email);

-- Verify the index is used:
EXPLAIN ANALYZE SELECT 1 FROM suppressions WHERE email = 'test@example.com';
-- Expected: Index Scan using suppressions_email_unique

If a unique constraint is not appropriate (e.g., you allow multiple suppression reason entries per email), use a non-unique index instead:

CREATE INDEX idx_suppressions_email ON suppressions (email);

If Redis is used as the suppression store, use a SET data structure (SISMEMBER) for O(1) membership checks — do not store suppressed emails in a Redis LIST and iterate.