Why Pagination patterns in Supabase? - Purpose & Use Cases

The Big Idea

What if your app could load huge lists instantly without freezing or crashing?

The Scenario

Imagine you have a huge list of items, like thousands of photos or messages, and you try to load them all at once on your app or website.

It feels like trying to carry all your groceries in one trip--heavy and overwhelming.

The Problem

Loading everything at once makes your app slow and clunky.

It can crash or freeze because it tries to handle too much data at the same time.

Also, users have to wait a long time before seeing anything useful.

The Solution

Pagination breaks the big list into small, easy-to-handle pages.

It's like carrying groceries in small bags instead of one huge load.

This way, your app loads faster and feels smooth.

Before vs After

✗ Before

SELECT * FROM photos;

✓ After

SELECT * FROM photos LIMIT 10 OFFSET 20;

What It Enables

Pagination lets users browse large data smoothly and quickly, improving their experience and saving resources.

Real Life Example

When you scroll through Instagram or Twitter, you don't load all posts at once.

Instead, you see a few posts, and more load as you scroll--this is pagination in action.

Key Takeaways

Loading all data at once is slow and risky.

Pagination splits data into small chunks for faster loading.

This improves app speed and user experience.

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