Skip to main content

​
Overview

pg_strict intercepts queries at parse time and blocks operations that are likely to be mistakes. When enabled, it prevents accidental mass updates or deletes that could affect your entire table.

​
Enabling pg_strict

pg_strict is configured per-role when creating new roles in the dashboard.
1
From the PlanetScale organization dashboard, select the desired database
2
Navigate to Settings > Roles
3
Click New role
4
Configure the role permissions
5
Under pg_strict, select a mode for each setting
6
Click Create role

​
Modes

Each pg_strict setting supports three modes:
ModeBehavior
offDisabled, standard PostgreSQL behavior
warnLog a warning but allow the query to run
onBlock the query with an error

​
What it blocks

We’re actively expanding pg_strict with additional safety checks. More configurations will be added soon to help prevent other common mistakes.

​
UPDATE without WHERE

When pg_strict.require_where_on_update is enabled, UPDATE statements must include a WHERE clause: 
-- Blocked (affects all rows)
UPDATE users SET status = 'inactive';

-- Allowed (targets specific rows)
UPDATE users SET status = 'inactive' WHERE last_login < '2024-01-01';

​
DELETE without WHERE

When pg_strict.require_where_on_delete is enabled, DELETE statements must include a WHERE clause: 
-- Blocked (deletes all rows)
DELETE FROM sessions;

-- Allowed (targets specific rows)
DELETE FROM sessions WHERE expired_at < NOW();

​
Overriding for one-off operations

For intentional bulk operations, use SET LOCAL within a transaction to temporarily disable a specific check: 
BEGIN;
SET LOCAL pg_strict.require_where_on_delete = off;
DELETE FROM temp_import_data;  -- Allowed within this transaction
COMMIT;
-- Setting restored after commit

​
Per-role configuration examples

Different roles can have different pg_strict settings based on their use case. For example, you may have a migration user that is allowed to do mass modifications, whereas roles that connect from app servers are not allowed to do so.