Filament 3.0 Table Pagination: Default paginate() vs simplePaginate()

Confirmed Answer

By default, Filament 3.0 Table components invoke Eloquent's paginate(), not simplePaginate(). The table's record-resolution logic (in the InteractsWithTableRecords concern used by the HasTable trait) calls $query->paginate($this->getTableRecordsPerPage()), which executes a COUNT(*) query before fetching the current page. This applies to Filament 3.x; verify against your installed version, since internals can shift between minor releases.

Can You Switch to simplePaginate()?

There is no global configuration flag or hook to change the pagination method. The only route is overriding the record-fetching method per Table class (Resource, Page, or Widget):

protected function getTableRecords(): \Illuminate\Contracts\Pagination\Paginator
{
    return $this->getTableQuery()->simplePaginate($this->getTableRecordsPerPage());
}

The per-page default of 10 is separately adjustable via ->defaultPaginationPageOption(25) or ->paginationPageOptions([10, 25, 50]), but that does not change the pagination method.

Memory and Cost Impact

• PHP memory is nearly identical: both methods hydrate only the current page's models. The premise that paginate() "loads the full result set" is incorrect—it loads one page plus runs a count.
• The COUNT(*) query is the real difference. On indexed tables up to a few million rows it is typically tens of milliseconds; on unindexed or heavily joined queries it can reach hundreds of milliseconds.
• Hosting cost matters only on metered/CPU-limited plans with frequent table renders against very large, unindexed tables.

Trade-off of Switching

simplePaginate() fetches limit + 1 rows and skips the count, but it returns no total or last page. Filament's default pagination UI (numbered pages, total count, "last" link) depends on a LengthAwarePaginator, so switching degrades the UI to previous/next unless you build custom controls.

Verification Steps

1. Inspect vendor/filament/tables/src/ for the paginate( call in the record-resolution concern.
2. Run DB::enableQueryLog(), render the table, and confirm a COUNT(*) precedes the limited SELECT.
3. Benchmark with EXPLAIN SELECT COUNT(*) FROM your_table; to decide whether the count is actually your bottleneck.

Recommendation

For low-traffic sites, keep the default. If the count query is genuinely expensive (complex joins, GROUP BY, 5M+ unindexed rows), prefer a cached count or covering index over simplePaginate(), which sacrifices the pagination UX.