Pagination patterns in Supabase - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is pagination in the context of databases?

Pagination is a way to split large sets of data into smaller, manageable chunks or pages, so users can view data step-by-step instead of all at once.

intermediate

What is the difference between offset-based and cursor-based pagination?

Offset-based pagination uses a page number or offset to skip records, while cursor-based pagination uses a unique value (cursor) from the last item to fetch the next set, making it more efficient for large or changing datasets.

beginner

How does Supabase support pagination in queries?

Supabase supports pagination by allowing you to use methods like .range(start, end) for offset-based pagination and by using filters with unique column values for cursor-based pagination.

intermediate

Why is cursor-based pagination preferred over offset-based pagination for large datasets?

Cursor-based pagination is preferred because it avoids performance issues caused by skipping many rows and handles data changes better, ensuring consistent results when data is added or removed.

beginner

What is a common real-life example of pagination?

A common example is browsing search results or social media feeds where only a few items show at a time, and you click 'Next' or scroll to load more, instead of loading everything at once.

Which pagination method uses a unique value from the last item to fetch the next set?

A Cursor-based pagination

B Offset-based pagination

C Page number pagination

D Limit-based pagination

Cursor-based pagination uses a unique cursor value from the last item to get the next page.

In Supabase, which method helps implement offset-based pagination?

A .select()

B .range(start, end)

C .order()

D .filter()

The .range(start, end) method in Supabase fetches rows between start and end indexes, enabling offset-based pagination.

Why might offset-based pagination cause performance issues on large datasets?

A It requires complex joins

B It uses too much memory

C It does not support sorting

D It skips many rows which slows down queries

Offset-based pagination skips rows which can slow down queries as the offset grows large.

Which of these is NOT a benefit of cursor-based pagination?

A Always returns the same number of rows

B Avoids skipping rows

C Handles data changes well

D Improves performance on large datasets

Cursor-based pagination may return varying numbers of rows depending on data changes; it does not guarantee a fixed count.

What is a simple way to explain pagination to a friend?

A Downloading all data at once

B Deleting old data automatically

C Showing data in small pages instead of all at once

D Sorting data alphabetically

Pagination means showing data in small pages so it's easier to view and manage.

Explain the two main pagination patterns and when to use each in Supabase.

Think about skipping rows vs using a pointer to the last item.

Describe why cursor-based pagination is better for large or frequently changing datasets.

Consider what happens when data changes between pages.

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