Bird
Raised Fist0
Supabasecloud~5 mins

Update and delete policies in Supabase - Time & Space Complexity

Choose your learning style10 modes available
Time Complexity: Update and delete policies
O(n)
Understanding Time Complexity

When using update and delete policies in Supabase, it's important to understand how the number of operations grows as data changes.

We want to know how the time to apply these policies changes when more rows are updated or deleted.

Scenario Under Consideration

Analyze the time complexity of the following operation sequence.


// Update rows with policy check
const { data, error } = await supabase
  .from('tasks')
  .update({ status: 'done' })
  .eq('user_id', currentUserId)

// Delete rows with policy check
const { data: delData, error: delError } = await supabase
  .from('tasks')
  .delete()
  .eq('completed', true)

This sequence updates tasks for a user and deletes completed tasks, both subject to row-level policies.

Identify Repeating Operations

Identify the API calls, resource provisioning, data transfers that repeat.

  • Primary operation: Each update or delete request triggers a policy check on matching rows.
  • How many times: The policy check runs once per affected row during update or delete.
How Execution Grows With Input

As the number of rows to update or delete grows, the number of policy checks grows similarly.

Input Size (n)Approx. API Calls/Operations
1010 policy checks
100100 policy checks
10001000 policy checks

Pattern observation: The number of policy checks grows directly with the number of rows affected.

Final Time Complexity

Time Complexity: O(n)

This means the time to apply update or delete policies grows linearly with the number of rows changed.

Common Mistake

[X] Wrong: "Policies run once per request, so time stays the same no matter how many rows are updated or deleted."

[OK] Correct: Each row affected must be checked against the policy, so more rows mean more checks and longer time.

Interview Connect

Understanding how policies affect operation time helps you design efficient database interactions and explain your reasoning clearly in discussions.

Self-Check

"What if we batch updates in smaller groups instead of one large update? How would the time complexity change?"

Practice

(1/5)
1. What is the main purpose of an UPDATE policy in Supabase?
easy
A. To control who can add new data to a table
B. To control who can read data from a table
C. To control who can change existing data in a table
D. To control who can create new tables

Solution

  1. Step 1: Understand the role of update policies

    Update policies define who is allowed to modify existing rows in a table.
  2. Step 2: Differentiate from other policies

    Read policies control reading, insert policies control adding data, and table creation is unrelated.
  3. Final Answer:

    To control who can change existing data in a table -> Option C
  4. Quick Check:

    Update policy = control data changes [OK]
Hint: Update policies control data changes, not reads or inserts [OK]
Common Mistakes:
  • Confusing update with read or insert policies
  • Thinking update policies control table creation
  • Assuming update policies allow adding new rows
2. Which keyword is used in Supabase policies to add extra conditions that must be true for an update to succeed?
easy
A. WITH CHECK
B. USING
C. ALLOW
D. WHERE

Solution

  1. Step 1: Identify keywords for policy conditions

    Supabase uses USING to specify who can perform an action and WITH CHECK to add extra conditions on updates.
  2. Step 2: Match keyword to extra conditions on update

    WITH CHECK ensures the new data meets certain rules before update is allowed.
  3. Final Answer:

    WITH CHECK -> Option A
  4. Quick Check:

    Extra update conditions = WITH CHECK [OK]
Hint: Use WITH CHECK for extra update conditions, USING for who can act [OK]
Common Mistakes:
  • Confusing USING and WITH CHECK keywords
  • Thinking WHERE is used in policies
  • Assuming ALLOW is a valid keyword
3. Given this update policy snippet:
CREATE POLICY "Update own profile" ON profiles
FOR UPDATE
USING (auth.uid() = profiles.user_id)
WITH CHECK (auth.uid() = profiles.user_id);

What happens if a user tries to update another user's profile?
medium
A. The update is allowed because USING only controls delete actions
B. The update is denied because WITH CHECK condition fails
C. The update is allowed because WITH CHECK is ignored
D. The update is denied because USING condition fails

Solution

  1. Step 1: Understand USING condition role

    The USING clause controls who can perform the update. It checks if the user's ID matches the profile's user_id.
  2. Step 2: Check condition for updating another user's profile

    If a user tries to update a different profile, auth.uid() = profiles.user_id is false, so update is denied.
  3. Final Answer:

    The update is denied because USING condition fails -> Option D
  4. Quick Check:

    USING controls update permission = denied if false [OK]
Hint: USING controls who can update; false means deny [OK]
Common Mistakes:
  • Thinking WITH CHECK controls permission to update
  • Assuming USING applies only to deletes
  • Ignoring that both USING and WITH CHECK must pass
4. You wrote this delete policy:
CREATE POLICY "Delete own posts" ON posts
FOR DELETE
USING (user_id = auth.uid());

But users report they cannot delete their posts. What is the likely problem?
medium
A. The policy should use WITH CHECK instead of USING
B. The policy might be missing enabling RLS on the table
C. The policy is correct; problem is elsewhere
D. The policy is missing FOR UPDATE clause

Solution

  1. Step 1: Check policy syntax

    The policy syntax is correct for delete with USING condition matching user_id.
  2. Step 2: Consider RLS status

    If Row Level Security (RLS) is not enabled on the table, policies have no effect and all actions are denied by default.
  3. Final Answer:

    The policy might be missing enabling RLS on the table -> Option B
  4. Quick Check:

    RLS must be enabled for policies to work [OK]
Hint: Enable RLS on table to activate policies [OK]
Common Mistakes:
  • Confusing USING and WITH CHECK for delete policies
  • Forgetting to enable RLS on the table
  • Thinking FOR UPDATE is needed for delete policies
5. You want to allow users to update their own orders only if the order status is not 'shipped'. Which policy correctly enforces this?
hard
A. FOR UPDATE USING (auth.uid() = orders.user_id) WITH CHECK (new.status != 'shipped')
B. FOR UPDATE USING (auth.uid() = orders.user_id) WITH CHECK (orders.status != 'shipped')
C. FOR UPDATE USING (auth.uid() = orders.user_id AND orders.status != 'shipped')
D. FOR UPDATE USING (auth.uid() = orders.user_id AND new.status != 'shipped')

Solution

  1. Step 1: Understand USING vs WITH CHECK

    USING controls who can perform the update; WITH CHECK ensures the new data meets conditions.
  2. Step 2: Apply condition on new data

    The status check must apply to the new value after update, so use new.status != 'shipped' in WITH CHECK.
  3. Step 3: Verify options

    FOR UPDATE USING (auth.uid() = orders.user_id) WITH CHECK (new.status != 'shipped') correctly uses USING (auth.uid() = orders.user_id) and WITH CHECK (new.status != 'shipped').
  4. Final Answer:

    FOR UPDATE USING (auth.uid() = orders.user_id) WITH CHECK (new.status != 'shipped') -> Option A
  5. Quick Check:

    Use WITH CHECK with new. for update conditions [OK]
Hint: Use WITH CHECK with new. to check updated values [OK]
Common Mistakes:
  • Checking old data instead of new data in WITH CHECK
  • Putting status condition in USING instead of WITH CHECK
  • Forgetting to use new. prefix for updated row
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard