Complete Guide to Filament Slow On Large Table? Optimize With Postgres Partitions
Posted on Jan 13
• Originally published at filamentmastery.com on Jan 13
When I started working on a client project, I ran into a familiar challenge: a Filament Resource managing millions of sensor measurements. The table contained several years of historical data. Most users usually focused on the current month, but occasionally they needed to look back at older measurements for special cases. At first, it looked like the resource was slow simply due to its sheer size, but profiling revealed a deeper issue. It became clear that Filament itself was not the bottleneck, the database was.
Filtering by date or sensor type took several seconds, even for just the current month. Sorting and pagination felt sluggish. It was a classic case of “everything works, but not fast enough for production.” The goal was simple: allow fast access to current data while keeping historical queries possible, without rewriting the panel.
The example below has been simplified for clarity. In the real project, additional filters and performance optimizations were applied. Default dates focus on the current month, but older data queries remain fully supported. The project was built with FilamentPHP and PostgreSQL.
To solve the problem, I used PostgreSQL table partitioning, splitting the data by month. Here’s a simplified example:
Partitioning ensures queries for the current month only scan a small, relevant subset, keeping performance high. Historical queries still work efficiently by targeting older partitions.
I created a scheduled job to automatically create new year/month partitions. More information about PostgreSQL partitioning is available in the official PostgreSQL documentation
Indexes must be created on each partition, not on the parent table. For example:
This ensures that even with filters, the database can quickly find the relevant rows.
Finally, I adapted the Filament Resource with default filters for the current month:
Source: Dev.to
