PostgreSQL 18: I/O assíncrono, UUIDv7 e o que muda em SaaS

Resposta atômica: PostgreSQL 18 trouxe um novo subsistema de I/O assíncrono (AIO) com ganhos demonstrados de até 3x em leitura de storage, skip scan para multicolumn B-tree indexes, função nativa uuidv7(), virtual generated columns como padrão, OAuth para autenticação e preservação de estatísticas de planner em major upgrades. Para SaaS multi-tenant rodando Postgres, esse é o upgrade mais relevante em anos.

O ganho que mais impacta SaaS: AIO

Antes da 18, leituras de storage no Postgres eram síncronas. O processo bloqueava enquanto o sistema operacional buscava a página em disco. Em workloads pesadas de leitura — listagens, agregações, scans — isso era latência grátis.

PostgreSQL 18 introduz asynchronous I/O subsystem. Operações como sequential scan, bitmap heap scan e VACUUM agora podem disparar múltiplas leituras concorrentes. Ganho documentado de até 3x em leitura de storage.

Para SaaS multi-tenant, isso muda dois cenários:

1. Relatórios cross-tenant (admin areas, dashboards de operação) ficam significativamente mais rápidos.
2. VACUUM corre em janelas menores, reduzindo impacto em horário comercial.

Skip scan: multicolumn index mais útil

Antes da 18, índice (a, b, c) era usado apenas quando a query filtrava por a (a coluna líder). Filtros em b ou c sem condição em a faziam seq scan.

PostgreSQL 18 introduz skip scan: o planner consegue "pular" valores distintos da coluna líder e usar o índice mesmo quando ela não está na query.

CREATE INDEX idx_invoices ON invoices (tenant_id, status, created_at);
-- pós-18: queries com WHERE status = 'open' (sem tenant_id, em rotas admin)
-- podem usar o índice via skip scan

Em SaaS, o efeito é grande em rotas administrativas e exports que cruzam tenants.

uuidv7(): a função que deveria ter existido há 5 anos

UUID v4 (aleatório) é o padrão default em quase todo SaaS brasileiro. O problema: inserts em tabela com índice sobre id uuid causam fragmentação no B-tree, porque cada novo UUID cai em uma posição arbitrária do índice.

UUID v7 resolve isso: timestamp na frente, aleatoriedade no fim. Inserts ficam sequenciais — write throughput e cache locality melhoram.

Antes da 18 era preciso extensão ou geração no aplicativo. Agora é nativo:

ALTER TABLE invoices
  ALTER COLUMN id SET DEFAULT uuidv7();

Migrar UUIDs existentes não é trivial (mudar tipo causa reescrita), mas toda tabela nova nasce com uuidv7() sem custo.

Virtual generated columns como padrão

Generated columns existiam desde a 12, mas eram sempre stored. Na 18, são virtual por padrão: o valor é computado no momento da leitura.

ALTER TABLE invoices ADD COLUMN
  total_with_tax numeric GENERATED ALWAYS AS (amount * (1 + tax_rate)) VIRTUAL;

Não ocupa storage, sempre consistente com a fórmula, dispensa lógica espalhada na aplicação.

OAuth para autenticação

Antes da 18, integrar Postgres com SSO empresarial exigia camada intermediária (PgBouncer + script de autenticação, LDAP, etc). Agora há OAuth nativo.

Para enterprise com requisito de SSO ao banco, é a peça que faltava para conformidade.

Preservação de estatísticas em major upgrade

Detalhe operacional crítico: até a 18, major upgrade significava jogar fora todas as estatísticas do planner. Após o upgrade, o banco rodava lento até ANALYZE reconstruir tudo.

Na 18, as estatísticas são preservadas. Após o upgrade, o cluster atinge performance esperada em minutos, não horas.

Como decidir o upgrade

1. Você está em PG 16+ — upgrade é low-risk. AIO e skip scan entregam ganho imediato. Validar em staging, planejar janela de 1-2h em produção.

2. Você está em PG 14 ou 15 — vale skipar para 18 direto. Cada major preservar estatísticas economiza horas em cada futuro upgrade.

3. Você está em PG 13 ou mais antigo — saia logo. Está em fim de suporte. Plano de migração para 18 deve ser sprint dedicado.

Checklist pré-upgrade

• Snapshot completo (pg_dump + base backup)
• Validação em staging com dump de produção real
• Verificar extensões em uso (algumas precisam de versão compatível)
• Benchmark de queries críticas antes/depois
• Plano de rollback documentado

Próximo passo

Para times que querem rodar esse upgrade com disciplina (validação em staging, ADR, gate de regressão, janela de manutenção planejada): exatamente o tipo de trabalho onde squad sênior com discovery de uma semana paga.

Fontes citadas

1. PostgreSQL 18 Released! — PostgreSQL · acessado em 2026-05-19
2. PostgreSQL 18.0 Release Notes · acessado em 2026-05-19
3. PostgreSQL 18 Press Kit · acessado em 2026-05-19