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.