Many developers assume PostgreSQL materialized views handle incremental updates out of the box. They do not. If you have a materialized view with millions of rows and a single underlying record changes, both native refresh options process the entire dataset.
Because of this limitation, anyone needing immediate maintenance or working with large datasets must abandon materialized views entirely. The standard workaround is to manually maintain a standard table using custom database triggers or application logic.
I've been working on a patch to fix this. It adds an optional WHERE clause to the REFRESH MATERIALIZED VIEW command, letting you scope a refresh to exactly the rows that changed. The patch is currently under review on the pgsql-hackers mailing list.
This approach requires two things. First, the materialized view must have a unique index (the same requirement as REFRESH MATERIALIZED VIEW ... CONCURRENTLY). Second, the