¿Cómo funcionan las vistas materializadas en PostgreSQL?

Question

Accepted Answer

Una **vista materializada** almacena los *resultados* de una consulta físicamente (precomputados), a diferencia de una vista regular (que vuelve a ejecutar su consulta cada vez). Esto hace que la lectura sea rápida para consultas costosas, a costa de que los datos sean tan frescos como el último **refresco** — un mecanismo de caché dentro de la base de datos.

## Vista regular vs vista materializada

```sql
-- regular VIEW — runs the query EVERY time (always fresh, but recomputed)
CREATE VIEW sales_summary AS SELECT region, SUM(amount) FROM orders GROUP BY region;

-- MATERIALIZED VIEW — stores the RESULTS physically (fast reads, but can be stale)
CREATE MATERIALIZED VIEW sales_summary_mat AS
SELECT region, SUM(amount) AS total FROM orders GROUP BY region;

SELECT * FROM sales_summary_mat;     -- reads STORED results — fast (no recompute)
```

Una vista materializada precomputa y almacena los resultados, por lo que consultarla es rápido (como leer una tabla) — ideal para agregaciones costosas consultadas frecuentemente.

## Refrescando (actualizando los datos almacenados)

```sql
-- the data is stale until you refresh it
REFRESH MATERIALIZED VIEW sales_summary_mat;          -- recompute (locks reads during refresh)

-- CONCURRENTLY — refresh WITHOUT blocking reads (requires a unique index)
CREATE UNIQUE INDEX idx_sales_region ON sales_summary_mat(region);
REFRESH MATERIALIZED VIEW CONCURRENTLY sales_summary_mat;   -- reads continue during refresh
```

Debes **refrescar** para actualizar los datos. `REFRESH ... CONCURRENTLY` (que requiere un índice único) actualiza sin bloquear lecturas concurrentes — importante para producción.

## Cuándo usar vistas materializadas

```text
✓ EXPENSIVE queries (complex aggregations, joins) queried FREQUENTLY
✓ Data that doesn't need real-time freshness (dashboards, reports, analytics)
✓ Reducing load from repeatedly running the same heavy query
→ Refresh on a schedule (cron / pg_cron) or after data changes.

✗ Data needing real-time accuracy → use a regular view or query directly
```

## La compensación

```text
Fast reads (precomputed) ⟷ Stale data (until refreshed) + storage cost.
You trade freshness and storage for read speed — a caching decision.
You can also index a materialized view (it's a physical table of results).
```

## Por qué es importante

Las vistas materializadas son una característica valiosa de PostgreSQL para **optimización de rendimiento** — proporcionan un mecanismo de caché en la base de datos para consultas costosas, por lo que comprenderlas es útil para optimizar aplicaciones con consultas costosas que se ejecutan frecuentemente.

El valor central es precomputar y almacenar los resultados de consultas costosas (agregaciones complejas, joins pesados) para que leerlas sea rápido (como consultar una tabla) en lugar de volver a ejecutar la consulta costosa cada vez — lo cual es una optimización significativa para dashboards, reportes y análisis donde la misma consulta pesada se ejecuta repetidamente.

Comprender la **compensación** clave es importante: las vistas materializadas dan lecturas rápidas pero los datos están **obsoletos** hasta que se refrescan (y cuestan almacenamiento), por lo que son una decisión de caché adecuada para datos que no necesitan frescura en tiempo real.

Saber cómo **refrescarlas** — especialmente `REFRESH ... CONCURRENTLY` (que actualiza sin bloquear lecturas, importante para disponibilidad en producción, requiere un índice único) — y estrategias de refresco (en un horario vía cron/pg_cron, o después de cambios de datos) es conocimiento práctico para usarlas efectivamente.

Comprender **cuándo usar** vistas materializadas (consultas costosas, frecuentemente ejecutadas, tolerantes a ligera obsolescencia — dashboards, análisis) versus cuándo no usarlas (datos que necesitan exactitud en tiempo real) refleja buen criterio.

Ya que consultas costosas repetidas son una preocupación real de rendimiento, y dado que las vistas materializadas proporcionan una solución efectiva de caché en la base de datos (resultados precomputados, indexables) con una compensación clara entre frescura y velocidad, comprenderlas — cómo funcionan, refrescando (especialmente concurrentemente), la compensación, y uso apropiado — es conocimiento valioso y prácticamente relevante de PostgreSQL para optimizar rendimiento de consultas analíticas y de reportes, una necesidad común donde las vistas materializadas ofrecen una solución limpia y integrada.