Filament Table Builder: Pagination performance on large datasets

Direct answer

Filament Table Builder does not provide a native switch to cursor-based pagination. It renders Laravel's length-aware paginator, which requires a total row count and a last-page number. Returning cursorPaginate() from the table query hook is not a supported drop-in because CursorPaginator does not expose total() or lastPage(), so the built-in pagination controls and the "of N" summary can break.

To bound a high-volume table, constrain the base query in the table's query hook, keep the page size bounded, and replace heavy relationship eager loads with aggregate subqueries rather than hydrating full collections.

Likely explanation versus confirmed facts

The deep-page slowdown is likely caused by two separate database behaviors, not by a Filament defect: the OFFSET scan cost on deep pages and the COUNT(*) that length-aware pagination runs to render the summary. Which one dominates changes the fix, so treat them as distinct until measured.

Confirmed from the builder's design: the table reads paginator metadata to display page links and totals. Confirmed from Laravel: cursorPaginate() returns a different paginator object with a different API. The exact hook names and column aggregate helpers are version-sensitive; in Filament v3 the query hook is query(), while earlier versions used modifyQueryUsing(). Verify against your installed source before relying on a specific method name.

Steps to bound the query

1. In the table query hook, select only needed columns and push filters into SQL. For example, in Filament v3 the hook is query(); in earlier versions it may be modifyQueryUsing(). Verify the method name in your installed source.

// Example pattern; confirm the hook name for your version
$table->query(function (Builder $query) {
    return $query->select(['id', 'name'])->withCount('items');
});

1. Cap the reachable page range and keep the page size bounded with paginated() or defaultPaginationPageOption(). Never call get() on the full table.
2. For relationships that would hydrate large hasMany collections, use withCount() or a count column instead. If you must eager load, constrain the relationship with a closure that selects limited columns.
3. Add composite indexes on the columns used for sorting and filtering so the remaining offset pages stay cheap.

One diagnostic detail

Before applying the steps above, determine whether the slow part is the OFFSET scan or the COUNT(*). If the count dominates, bounding rows alone will not help; you would need to avoid or cache the total instead. Sharing which query dominates changes the recommendation.

Conservative note: This draft reflects documented Laravel and Filament behavior but requires verification against your exact installed versions. Enable query logging locally, load the deepest page, and inspect the emitted SQL to confirm you see one bounded SELECT plus a separate COUNT, not a full get().