Pagination patterns in Supabase - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

Understanding Offset Pagination Behavior

You have a Supabase table with 1000 rows. You use offset pagination with limit=10 and offset=20. What rows will you get?

Supabase

const { data, error } = await supabase
  .from('items')
  .select('*')
  .range(20, 29);

A Rows 21 to 30 (inclusive) from the table

B Rows 20 to 29 (inclusive) from the table

C Rows 19 to 28 (inclusive) from the table

D Rows 11 to 20 (inclusive) from the table

💡 Hint

Remember that offset starts counting from zero, so offset 20 means skipping the first 20 rows.

Supabase's range(start, end) method includes rows from start to end inclusive, zero-based. So range(20, 29) returns rows 21 to 30.

❓ Architecture

intermediate

Choosing Pagination Strategy for Large Datasets

You want to build a Supabase app that lists millions of records. Which pagination method is best to ensure fast, consistent loading?

A Use cursor-based pagination with a unique column like <code>id</code> for filtering

B Use offset pagination with <code>limit</code> and <code>offset</code> parameters

C Load all records at once and paginate on the client side

D Use random sampling to fetch random pages

💡 Hint

Think about how offset pagination slows down with large offsets.

Offset pagination becomes slower as offset grows because the database must skip many rows. Cursor-based pagination uses a unique column to fetch the next set efficiently, making it better for large datasets.

❓ security

advanced

Preventing Data Leakage in Pagination

You implement cursor pagination in Supabase using a timestamp column. What security risk might occur if you expose raw timestamps as cursors in URLs?

A Timestamps cause the database to crash under load

B Users can guess and access unauthorized data by manipulating timestamps

C Cursor pagination will return duplicate rows

D There is no security risk with exposing timestamps

💡 Hint

Think about what happens if users change the cursor value manually.

Exposing raw timestamps allows users to guess cursor values and potentially access data they shouldn't see. It's safer to encode cursors or use opaque tokens.

✅ Best Practice

advanced

Implementing Stable Pagination with Concurrent Data Changes

In a Supabase app, data changes frequently. Which pagination pattern helps avoid skipping or repeating rows when new rows are inserted during pagination?

A Use random page numbers to avoid duplicates

B Use offset pagination with fixed offsets

C Reload the first page every time to reset pagination

D Use cursor pagination based on a stable unique column like <code>id</code>

💡 Hint

Consider how new rows affect offset positions.

Offset pagination can skip or repeat rows if data changes during pagination. Cursor pagination with a stable unique column avoids this by always starting after the last seen item.

🧠 Conceptual

expert

Analyzing Pagination Query Performance

Given a Supabase table with an index on created_at, which query will perform best for paginating 10,000+ rows?

Options:

1. Offset pagination: select * from items order by created_at desc limit 10 offset 10000
2. Cursor pagination: select * from items where created_at < last_seen_created_at order by created_at desc limit 10

A Offset pagination query performs better because it uses limit and offset

B Both queries perform equally well on large datasets

C Cursor pagination query performs better because it uses indexed filtering

D Neither query will work on large datasets

💡 Hint

Think about how offset affects query execution time on large tables.

Offset pagination requires scanning and skipping many rows, which slows down as offset grows. Cursor pagination uses an indexed filter to jump directly to the next rows, improving performance.

Practice

1. What does the .range(from, to) method do in Supabase pagination?

easy

A. It sorts the rows between from and to indexes.

B. It limits the total number of rows returned to to.

C. It fetches rows starting from index from up to index to inclusive.

D. It skips the first from rows and returns the rest.

Solution

1. Step 1: Understand the purpose of .range(from, to)

   This method is used to select a slice of rows by index, starting at from and ending at to, inclusive.

2. Step 2: Compare options with this behavior

   Only the option stating 'It fetches rows starting from index from up to index to inclusive.' correctly describes the slicing behavior. The other options describe sorting, limiting, or skipping incorrectly.

3. Final Answer:

   It fetches rows starting from index from up to index to inclusive. -> Option C

4. Quick Check:

   .range(from, to) = fetch rows from-to inclusive [OK]

Hint: Remember range is inclusive from start to end index [OK]

Common Mistakes:

• Thinking to is exclusive
• Confusing .range with .limit
• Assuming it skips rows instead of slicing

2. Which of the following is the correct syntax to fetch page 3 with 10 items per page using Supabase's .range()?

easy

A. .range(20, 29)

B. .range(30, 39)

C. .range(21, 30)

D. .range(10, 19)

Solution

1. Step 1: Calculate start and end indexes for page 3

   Page 3 means items 21 to 30 (1-based). Since .range() uses 0-based indexes, start = (3-1)*10 = 20, end = 20 + 9 = 29.

2. Step 2: Match calculated range with options

   .range(20, 29) matches the correct 0-based slice for page 3.

3. Final Answer:

   .range(20, 29) -> Option A

4. Quick Check:

   Page 3 with 10 items = indexes 20 to 29 [OK]

Hint: Page N with size S starts at (N-1)*S [OK]

Common Mistakes:

• Using 1-based indexes directly
• Off-by-one errors in start or end
• Confusing page number with item count

3. Given this Supabase query:

const page = 2;
const pageSize = 5;
const { data } = await supabase
  .from('products')
  .select('*')
  .range((page - 1) * pageSize, page * pageSize - 1);

How many rows will data contain?

medium

A. 6

B. 10

C. 4

D. 5

Solution

1. Step 1: Calculate the range indexes

   For page 2 and pageSize 5, start = (2-1)*5 = 5, end = 2*5 - 1 = 9.

2. Step 2: Determine number of rows fetched

   Indexes 5 to 9 inclusive means 5 rows (5,6,7,8,9).

3. Final Answer:

   5 -> Option D

4. Quick Check:

   Range length = end - start + 1 = 5 [OK]

Hint: Count rows as end - start + 1 [OK]

Common Mistakes:

• Counting end index as exclusive
• Miscalculating start or end
• Assuming pageSize is ignored

4. You wrote this code to fetch page 1 with 10 items per page:

const page = 1;
const pageSize = 10;
const { data } = await supabase
  .from('orders')
  .select('*')
  .range(page * pageSize, (page + 1) * pageSize - 1);

Why does this return no rows?

medium

A. Because .range() requires the start index to be less than the end index.

B. Because the range starts at 10 instead of 0, skipping the first page.

C. Because pageSize must be 0 for the first page.

D. Because .select('*') must be called after .range().

Solution

1. Step 1: Analyze the range calculation

   For page 1 and pageSize 10, start = 1*10 = 10, end = (1+1)*10 - 1 = 19. This skips rows 0 to 9.

2. Step 2: Understand why no rows appear

   If the table has fewer than 11 rows or you want the first page, you must start at 0. Starting at 10 skips the first 10 rows.

3. Final Answer:

   Because the range starts at 10 instead of 0, skipping the first page. -> Option B

4. Quick Check:

   Page 1 start index = 0, not 10 [OK]

Hint: Page 1 starts at index 0, not page * pageSize [OK]

Common Mistakes:

• Starting range at page * pageSize instead of (page-1)*pageSize
• Misunderstanding zero-based indexing
• Incorrect order of method calls

5. You want to implement infinite scrolling with Supabase pagination. Which approach correctly fetches the next page of 15 items after receiving the first page?

hard

A. Use .range(0, 14) for first page, then .range(15, 29) for second page.

B. Use .range(1, 15) for first page, then .range(16, 30) for second page.

C. Use .range(0, 15) for first page, then .range(15, 30) for second page.

D. Use .range(0, 14) for first page, then .range(14, 29) for second page.

Solution

1. Step 1: Define correct zero-based ranges for pages

   For 15 items per page, first page is indexes 0 to 14 (15 items). Second page starts at 15 and ends at 29.

2. Step 2: Match options with correct ranges

   The option using .range(0, 14) for first page, then .range(15, 29) for second page is correct. It avoids off-by-one errors or overlaps present in the others.

3. Final Answer:

   Use .range(0, 14) for first page, then .range(15, 29) for second page. -> Option A

4. Quick Check:

   Pages must not overlap and cover all items [OK]

Hint: Next page starts at previous end + 1 [OK]

Common Mistakes:

• Overlapping ranges causing duplicate items
• Off-by-one errors in start or end indexes
• Starting second page at wrong index