Como as views materializadas funcionam no PostgreSQL?

Question

Accepted Answer

Uma **view materializada** armazena os *resultados* de uma consulta fisicamente (pré-computados), ao contrário de uma view regular (que re-executa sua consulta a cada vez). Isso torna a leitura rápida para consultas caras, ao custo dos dados serem apenas tão atualizados quanto o último **refresh** — um mecanismo de cache dentro do banco de dados.

## View regular vs view 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)
```

Uma view materializada pré-computa e armazena os resultados, então consultá-la é rápido (como ler uma tabela) — ideal para agregações caras consultadas frequentemente.

## Atualizando (refrescando os dados armazenados)

```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
```

Você deve **fazer refresh** para atualizar os dados. `REFRESH ... CONCURRENTLY` (exigindo um índice único) atualiza sem bloquear leituras concorrentes — importante para produção.

## Quando usar views 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
```

## O trade-off

```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 que isso importa

As views materializadas são um recurso valioso do PostgreSQL para **otimização de performance** — elas fornecem um mecanismo de cache dentro do banco de dados para consultas caras, então entendê-las é útil para otimizar aplicações com consultas custosas e executadas frequentemente.

O valor principal é pré-computar e armazenar os resultados de consultas caras (agregações complexas, joins pesados) para que sua leitura seja rápida (como consultar uma tabela) em vez de re-executar a consulta cara cada vez — o que é uma otimização significativa para dashboards, relatórios e análises onde a mesma consulta pesada é executada repetidamente.

Entender o principal **trade-off** é importante: views materializadas oferecem leituras rápidas mas os dados são **obsoletos** até serem refrescados (e custam armazenamento), então são uma decisão de cache adequada para dados que não precisam de atualização em tempo real.

Saber como **refrescá-las** — especialmente `REFRESH ... CONCURRENTLY` (que atualiza sem bloquear leituras, importante para disponibilidade em produção, exigindo um índice único) — e estratégias de refresh (em um cronograma via cron/pg_cron, ou após mudanças de dados) é conhecimento prático para usá-las efetivamente.

Entender **quando usar** views materializadas (consultas caras, executadas frequentemente, tolerantes de certa obsolescência — dashboards, análises) versus quando não usar (dados que precisam de precisão em tempo real) reflete bom julgamento.

Como consultas repetidas caras são uma preocupação real de performance, e como views materializadas fornecem uma solução eficaz de cache dentro do banco de dados (resultados pré-computados, indexáveis) com um trade-off claro entre atualização e velocidade, entendê-las — como funcionam, atualizando (especialmente concorrentemente), o trade-off e uso apropriado — é conhecimento valioso e praticamente relevante do PostgreSQL para otimizar a performance de consultas analíticas e de relatórios, uma necessidade comum onde views materializadas oferecem uma solução limpa e nativa.