Database triggers help automate actions when data changes. They save time by doing tasks automatically without manual work.
Send a notification when a new user signs up.
Update a summary table after data changes.
Log changes for auditing automatically.
Enforce business rules like preventing invalid data.
Sync data between tables without extra code.
Syntax
Supabase
CREATE TRIGGER trigger_name
AFTER INSERT OR UPDATE OR DELETE ON table_name
FOR EACH ROW
EXECUTE FUNCTION function_name();
Triggers run automatically after specified events like INSERT, UPDATE, or DELETE.
You must create a function that the trigger calls to perform the automation.
Examples
This trigger logs every new user added to the users table.
Supabase
CREATE FUNCTION log_new_user() RETURNS trigger AS $$
BEGIN
INSERT INTO user_logs(user_id, action) VALUES (NEW.id, 'created');
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER after_user_insert
AFTER INSERT ON users
FOR EACH ROW
EXECUTE FUNCTION log_new_user();
This trigger updates a count of orders whenever a new order is added.
Supabase
CREATE FUNCTION update_order_count() RETURNS trigger AS $$
BEGIN
UPDATE stats SET order_count = order_count + 1 WHERE id = 1;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER after_order_insert
AFTER INSERT ON orders
FOR EACH ROW
EXECUTE FUNCTION update_order_count();
Sample Program
This example creates two tables: users and user_logs. It adds a trigger that logs every new user added. When we insert 'Alice' into users, the trigger adds a log entry automatically.
Supabase
CREATE TABLE users (
id SERIAL PRIMARY KEY,
name TEXT NOT NULL
);
CREATE TABLE user_logs (
log_id SERIAL PRIMARY KEY,
user_id INT NOT NULL,
action TEXT NOT NULL,
log_time TIMESTAMP DEFAULT NOW()
);
CREATE FUNCTION log_new_user() RETURNS trigger AS $$
BEGIN
INSERT INTO user_logs(user_id, action) VALUES (NEW.id, 'created');
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER after_user_insert
AFTER INSERT ON users
FOR EACH ROW
EXECUTE FUNCTION log_new_user();
-- Insert a new user to test the trigger
INSERT INTO users (name) VALUES ('Alice');
-- Check the logs
SELECT * FROM user_logs;
OutputSuccess
Important Notes
Triggers can slow down database operations if they do heavy work. Keep trigger functions simple and fast.
Test triggers carefully to avoid unwanted side effects or infinite loops.
Supabase uses PostgreSQL triggers, so standard PostgreSQL syntax applies.
Summary
Database triggers automate tasks when data changes.
They run functions after INSERT, UPDATE, or DELETE events.
Use triggers to keep data consistent and automate workflows without extra code.
Practice
(1/5)
1. What is the main purpose of a database trigger in Supabase?
easy
A. To manually update data in the database
B. To automatically run a function when data changes in a table
C. To create a backup of the database
D. To increase the database storage size
Solution
Step 1: Understand what triggers do
Triggers run automatically when data changes like insert, update, or delete.
Step 2: Identify the purpose in Supabase
Supabase triggers automate running functions on data changes without manual intervention.
Final Answer:
To automatically run a function when data changes in a table -> Option B
Quick Check:
Trigger = auto-run function on data change [OK]
Hint: Triggers run code automatically on data changes [OK]
Common Mistakes:
Thinking triggers require manual activation
Confusing triggers with backups
Assuming triggers increase storage
2. Which of the following is the correct syntax to create a trigger in Supabase SQL?
easy
A. CREATE TRIGGER trigger_name WHEN INSERT ON table_name EXECUTE function_name();
B. CREATE TRIGGER trigger_name BEFORE UPDATE table_name CALL function_name();
C. CREATE TRIGGER trigger_name ON table_name AFTER DELETE RUN function_name();
D. CREATE TRIGGER trigger_name AFTER INSERT ON table_name EXECUTE FUNCTION function_name();
Solution
Step 1: Recall correct trigger syntax in PostgreSQL (used by Supabase)
The correct syntax uses CREATE TRIGGER, timing (AFTER/BEFORE), event (INSERT/UPDATE/DELETE), ON table, and EXECUTE FUNCTION.
Step 2: Match options to syntax
CREATE TRIGGER trigger_name AFTER INSERT ON table_name EXECUTE FUNCTION function_name(); matches the correct syntax: CREATE TRIGGER name AFTER INSERT ON table EXECUTE FUNCTION func(); others use wrong keywords like CALL, RUN, or WHEN.
Final Answer:
CREATE TRIGGER trigger_name AFTER INSERT ON table_name EXECUTE FUNCTION function_name(); -> Option D
Quick Check:
CREATE TRIGGER ... EXECUTE FUNCTION ... [OK]
Hint: Use EXECUTE FUNCTION, not CALL or RUN in triggers [OK]
Common Mistakes:
Using CALL or RUN instead of EXECUTE FUNCTION
Missing ON keyword before table name
Using WHEN instead of BEFORE or AFTER
3. Given this trigger function in Supabase SQL:
CREATE FUNCTION log_insert() RETURNS trigger AS $$ BEGIN INSERT INTO logs(table_name, action) VALUES (TG_TABLE_NAME, 'insert'); RETURN NEW; END; $$ LANGUAGE plpgsql;
And this trigger:
CREATE TRIGGER after_insert_log AFTER INSERT ON users EXECUTE FUNCTION log_insert();
What happens when a new row is inserted into the users table?
medium
A. A new row is added to the logs table recording the insert action on users
B. The insert into users is blocked and logs table is updated
C. Nothing happens because the trigger is AFTER INSERT
D. The users table row is deleted after insert
Solution
Step 1: Understand the trigger function behavior
The function inserts a row into logs with the table name and action 'insert' whenever triggered.
Step 2: Understand the trigger timing and event
The trigger runs AFTER INSERT on users, so after a new user row is added, the function runs and logs the action.
Final Answer:
A new row is added to the logs table recording the insert action on users -> Option A
Quick Check:
AFTER INSERT triggers log insert action [OK]
Hint: AFTER INSERT triggers run after data is added [OK]
Common Mistakes:
Thinking AFTER INSERT blocks the insert
Assuming trigger does nothing
Confusing trigger timing with BEFORE
4. You wrote this trigger function:
CREATE FUNCTION update_timestamp() RETURNS trigger AS $$ BEGIN NEW.updated_at = NOW(); RETURN NEW; END; $$ LANGUAGE plpgsql;
And this trigger:
CREATE TRIGGER update_time BEFORE UPDATE ON orders EXECUTE FUNCTION update_timestamp();
But the updated_at column is not changing on updates. What is the likely problem?
medium
A. The trigger is AFTER UPDATE instead of BEFORE UPDATE
B. The trigger function is missing RETURN OLD
C. The trigger function does not modify NEW row correctly
D. The trigger function is not marked as VOLATILE
Solution
Step 1: Check how NEW row is modified in trigger
The function sets NEW.updated_at = NOW() but does not assign it back properly; in PL/pgSQL, you must assign NEW.updated_at and then RETURN NEW.
Step 2: Confirm trigger timing and return
The trigger is BEFORE UPDATE and returns NEW, which is correct. The problem is likely the function does not properly update the NEW record.
Final Answer:
The trigger function does not modify NEW row correctly -> Option C
Quick Check:
Modify NEW row correctly in BEFORE UPDATE triggers [OK]
Hint: Always RETURN NEW after modifying it in BEFORE UPDATE triggers [OK]
Common Mistakes:
Not returning NEW after changes
Using AFTER UPDATE instead of BEFORE UPDATE
Returning OLD instead of NEW
5. You want to automatically archive deleted rows from the products table into products_archive using a trigger. Which approach correctly achieves this in Supabase?
hard
A. Create an AFTER DELETE trigger on products that inserts OLD row into products_archive
B. Create a BEFORE DELETE trigger on products that deletes from products_archive
C. Create an AFTER INSERT trigger on products_archive that copies rows to products
D. Create a BEFORE UPDATE trigger on products that moves rows to products_archive
Solution
Step 1: Understand the goal
You want to save deleted rows from products into products_archive automatically.
Step 2: Choose correct trigger timing and action
AFTER DELETE trigger on products can access OLD row data and insert it into products_archive. BEFORE DELETE is too early to archive after deletion. Other options do not archive deleted rows.
Final Answer:
Create an AFTER DELETE trigger on products that inserts OLD row into products_archive -> Option A
Quick Check:
AFTER DELETE triggers archive OLD row [OK]
Hint: Use AFTER DELETE triggers to archive deleted rows [OK]
Common Mistakes:
Using BEFORE DELETE to archive after deletion
Confusing insert and delete triggers
Trying to archive on update instead of delete
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.