Subscribing to database changes in Supabase - Time & Space Complexity

Time Complexity: Subscribing to database changes

O(n)

Understanding Time Complexity

When we subscribe to database changes, we want to know how the work grows as more changes happen.

We ask: How does the number of updates affect the system's work?

Scenario Under Consideration

Analyze the time complexity of the following operation sequence.

const subscription = supabase
  .channel('table_changes')
  .on('postgres_changes', { event: '*', schema: 'public', table: 'messages' }, payload => {
    console.log('Change received:', payload)
  })
  .subscribe()

This code listens for all changes on the 'messages' table and runs a function each time a change happens.

Identify Repeating Operations

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

• Primary operation: Receiving and processing each database change event.
• How many times: Once per change event that occurs on the table.

How Execution Grows With Input

Each new change triggers one event call, so the work grows directly with the number of changes.

Input Size (n)	Approx. Api Calls/Operations
10	10 event calls
100	100 event calls
1000	1000 event calls

Pattern observation: The number of operations grows in a straight line with the number of changes.

Final Time Complexity

Time Complexity: O(n)

This means the work grows directly in proportion to the number of database changes received.

Common Mistake

[X] Wrong: "Subscribing to changes only triggers one operation no matter how many changes happen."

[OK] Correct: Each change sends a separate event, so the system processes each one individually, increasing work as changes increase.

Interview Connect

Understanding how event subscriptions scale helps you design systems that handle live updates smoothly and predict their load.

Self-Check

"What if we batch multiple changes into one event? How would the time complexity change?"

Practice

1. What does subscribing to database changes in Supabase help your app do?

easy

A. Keep app data live and updated automatically

B. Manually refresh data by reloading the page

C. Store data permanently on the client device

D. Encrypt data before sending to the database

Solution

1. Step 1: Understand the purpose of subscriptions

   Subscriptions listen for database changes and update the app data live.

2. Step 2: Compare options with subscription benefits

   Only Keep app data live and updated automatically describes automatic live updates, matching subscription behavior.

3. Final Answer:

   Keep app data live and updated automatically -> Option A

4. Quick Check:

   Subscriptions = live data updates [OK]

Hint: Subscriptions keep data live without manual refresh [OK]

Common Mistakes:

• Thinking subscriptions store data locally
• Confusing subscriptions with manual refresh
• Assuming subscriptions encrypt data

2. Which of the following is the correct syntax to subscribe to INSERT events on the 'messages' table in Supabase?

easy

A. supabase.from('messages').on('UPDATE', callback).subscribe()

B. supabase.from('messages').on('INSERT', callback).subscribe()

C. supabase.table('messages').listen('INSERT', callback).subscribe()

D. supabase.listen('messages').on('INSERT', callback).subscribe()

Solution

1. Step 1: Recall correct Supabase subscription syntax

   The correct method is supabase.from('table').on('EVENT', callback).subscribe().

2. Step 2: Match syntax to options

   supabase.from('messages').on('INSERT', callback).subscribe() matches this syntax with 'messages' and 'INSERT' event.

3. Final Answer:

   supabase.from('messages').on('INSERT', callback).subscribe() -> Option B

4. Quick Check:

   Correct syntax = supabase.from('messages').on('INSERT', callback).subscribe() [OK]

Hint: Use .from('table').on('EVENT', callback).subscribe() [OK]

Common Mistakes:

• Using .table() instead of .from()
• Listening to wrong event type
• Incorrect method chaining order

3. Given the code below, what will be logged when a new row is inserted into the 'tasks' table?

supabase.from('tasks').on('INSERT', payload => {
  console.log('New task:', payload.new);
}).subscribe()

medium

A. New task: undefined

B. No output because subscription is missing

C. Error: callback not defined

D. New task: [object Object] with new row data

Solution

1. Step 1: Understand the callback payload on INSERT

   The payload contains a 'new' property with the inserted row data as an object.

2. Step 2: Analyze console.log output

   Logging 'New task:' plus payload.new prints the object as '[object Object]' in console.

3. Final Answer:

   New task: [object Object] with new row data -> Option D

4. Quick Check:

   Payload.new logs inserted row object [OK]

Hint: payload.new holds inserted row data object [OK]

Common Mistakes:

• Expecting payload.new to be undefined
• Confusing payload.new with payload.old
• Assuming subscription needs extra setup to log

4. What is wrong with this subscription code?

const subscription = supabase.from('orders').on('DELETE', () => {
  console.log('Order deleted');
})

medium

A. Missing .subscribe() call to activate subscription

B. Wrong event type; should be 'REMOVE' instead of 'DELETE'

C. Callback function must receive a payload parameter

D. Subscription must be assigned to a variable named 'sub'

Solution

1. Step 1: Check subscription activation

   The .subscribe() method is required to start listening to events.

2. Step 2: Verify event type and callback

   'DELETE' is a valid event, and callback can omit payload if unused.

3. Final Answer:

   Missing .subscribe() call to activate subscription -> Option A

4. Quick Check:

   Always call .subscribe() to activate [OK]

Hint: Always end with .subscribe() to start listening [OK]

Common Mistakes:

• Forgetting .subscribe() call
• Using wrong event names
• Thinking callback must have parameters

5. You want to subscribe to both INSERT and UPDATE events on the 'profiles' table and log the changed row each time. Which code correctly achieves this?

hard

A. supabase.from('profiles').on('INSERT,UPDATE', payload => console.log(payload.new)).subscribe()

B. supabase.from('profiles').on(['INSERT', 'UPDATE'], payload => console.log(payload.new)).subscribe()

C. supabase.from('profiles').on('INSERT', payload => console.log(payload.new)).on('UPDATE', payload => console.log(payload.new)).subscribe()

D. supabase.from('profiles').on('INSERT').on('UPDATE', payload => console.log(payload.new)).subscribe()

Solution

1. Step 1: Understand event subscription chaining

   Supabase allows chaining .on() calls for different events before .subscribe().

2. Step 2: Evaluate each option's syntax

   supabase.from('profiles').on('INSERT', payload => console.log(payload.new)).on('UPDATE', payload => console.log(payload.new)).subscribe() chains .on('INSERT', ...).on('UPDATE', ...) correctly; others use invalid event formats.

3. Final Answer:

   supabase.from('profiles').on('INSERT', payload => console.log(payload.new)).on('UPDATE', payload => console.log(payload.new)).subscribe() -> Option C

4. Quick Check:

   Chain .on() for multiple events [OK]

Hint: Chain .on() calls for each event before .subscribe() [OK]

Common Mistakes:

• Trying to pass multiple events as array or comma string
• Calling .subscribe() too early
• Not chaining .on() properly