OLTP, OLAP e HTAP em produção: a decisão é workload

OLTP OLAP HTAP em produção costuma virar uma discussão sobre produto de banco de dados. Esse é o começo errado. A pergunta útil não é se um banco “é OLTP” ou “é OLAP”. A pergunta é qual workload você está colocando no sistema, que recurso ele consome, qual isolamento ele precisa e qual frescor de dado o negócio realmente exige.

PostgreSQL moderno consegue executar muita coisa que parece analítica: joins grandes, window functions, CTEs, materialized views, índices específicos, particionamento e extensões. Isso não transforma automaticamente o sistema transacional em uma boa plataforma analítica. Capacidade técnica e decisão arquitetural não são a mesma coisa.

OLTP, OLAP e HTAP em produção são decisões de isolamento?

Workload transacional costuma ser sensível a latência, concorrência e previsibilidade. Ele protege o caminho crítico do produto. Workload analítico tende a varrer mais dados, agregar mais linhas, consumir mais memória, pressionar I/O e disputar cache com o tráfego que paga a conta.

Quando uma query analítica roda no mesmo banco que atende checkout, pedido, antifraude, agenda ou contrato, ela não está “só lendo”. Ela compete por CPU, memória, disco, cache e capacidade operacional do time. Mesmo correta, pode estar no lugar errado.

Separar tudo cedo demais também cobra preço. Um pipeline analítico traz duplicação de dados, governança, observabilidade, retentativas, reprocessamento, schema evolution, segurança, backfill e custo de operação. A conta muda de lugar, mas não desaparece.

Analytics no banco transacional faz sentido quando?

Relatórios operacionais leves podem viver no banco transacional quando existe controle claro: volume previsível, janelas de execução, índices bem escolhidos, materializações pontuais, limites de concorrência e uma noção explícita do impacto no SLA. O problema começa quando “só mais um dashboard” vira carga recorrente, imprevisível e sem dono operacional.

Read replicas ajudam, mas não apagam a decisão. Elas reduzem a disputa com o primário, mas introduzem lag, leitura eventualmente desatualizada, conflitos possíveis e mais peças para monitorar. CDC e materialização assíncrona trazem outra lista de problemas: snapshot inicial, retenção de log, slots, ordenação, semântica de entrega e recuperação.

HTAP entra como alternativa legítima quando há necessidade real de misturar transação e análise com baixa latência de dados. Mas não remove tradeoff. Ele desloca o problema para isolamento interno, modelo de armazenamento, custo, maturidade operacional e lock-in.

Como decidir entre banco primário, réplica, CDC, warehouse ou HTAP?

“Tempo real” raramente é requisito suficiente. Para arquitetura, ele precisa virar número: quantos segundos ou minutos de frescor são aceitáveis, qual decisão depende disso, qual erro o negócio tolera e qual indisponibilidade o sistema pode absorver. Sem essa tradução, o time compra complexidade antes de entender o problema.

A decisão madura não começa escolhendo PostgreSQL, ClickHouse, Redshift, lakehouse ou uma solução HTAP. Começa separando workloads por risco. Se o analítico é leve, previsível e operacional, talvez fique perto do transacional. Se ameaça SLA, cresce sem controle ou precisa de histórico pesado, precisa sair. Se exige frescor baixo e isolamento forte, talvez HTAP ou uma arquitetura assíncrona faça sentido.

No fim, OLTP, OLAP e HTAP são nomes úteis, mas insuficientes. Importa a conta operacional: quem sofre contenção, quem monitora lag, quem corrige dado errado e quem atende o incidente quando a query certa roda no lugar errado.

Referências

Assista ao vídeo completo no YouTube →

Leia também