Skip to content

no-database-triggers

Keep behavioral logic in application code, not database triggers.

Why

Under a single-writer application architecture, triggers hide writes and state transitions from engineers reading application code and make the behavior difficult to exercise through ordinary unit-test seams. Triggers may still be appropriate for approved multi-writer integrity or audit needs.

Fix

Use a declarative database constraint where possible or explicit transactional application behavior; use an exact SARJ114 suppression when an approved database-owned invariant requires a trigger.

Examples

Before — flagged Hidden trigger behavior
supabase/migrations/001.sql
CREATE TRIGGER update_timestamp
BEFORE UPDATE ON calls
EXECUTE FUNCTION set_timestamp ();
After — preferred Declarative database invariant
supabase/migrations/001.sql
ALTER TABLE child
ADD CONSTRAINT child_tenant_fk FOREIGN KEY (organization_id, parent_id) REFERENCES parent (organization_id, id);

Formerly: no-create-trigger