Halodoc migra Redshift de RA3 para RG e reduz custos em 32% com consultas mais rápidas

A Halodoc tratou a migração do Redshift de RA3 para RG como algo que não podia ser dado como certo, mesmo com a AWS descrevendo o processo como um upgrade in-place (mesmo dialeto SQL, mesma porta, mesmo endpoint após um Elastic Resize). O data warehouse fica atrás de centenas de DAGs do Airflow, jobs Spark, dashboards, políticas de governança e exportações para outras ferramentas. Por isso o time restaurou o snapshot de produção em um cluster RG separado e montou onze verificações, cada uma com a condição de aprovação escrita antes da execução.

As checagens cobriram conexões, usuários, permissões e funções customizadas, carga via COPY de arquivos Parquet no S3, os dois caminhos de escrita (Spark com staging e merge, e SQL direto), exportações para a plataforma de marketing, manutenção e monitoramento, políticas de mascaramento, o setup Spark para Redshift, cursores server-side e, por fim, desempenho e planos de execução. Nada ficou mais lento no RG. O COPY de cerca de 6 milhões de linhas caiu de 145 para 24 segundos, a exportação em Parquet foi de 366 para 301 segundos e a construção de cinco tabelas pesadas de relatório ficou de 2,1x a 5,2x mais rápida. Os planos explicaram parte do ganho: o RG lê tabelas externas do S3 direto nos nós de computação, distribuiu só os dados necessários em vez de fazer broadcast de uma tabela de cerca de 10 milhões de linhas, e o RA3 planejava com estatísticas defasadas.

Na janela da manhã (7h às 13h), com cerca de 11.000 queries, o tempo em fila caiu cerca de 32% nos dashboards e 83% nos pipelines. Na visão semanal, a fila caiu cerca de 70% e o tempo médio de execução cerca de 35%. O uso de concurrency scaling caiu cerca de 45%, e o máximo de clusters extras foi reduzido de dois para um. O custo do cluster caiu 30%, o gasto com concurrency scaling 76%, o compute ficou cerca de 35% mais barato e a conta total, com storage, cerca de 32% menor. Um ponto de atenção: o job de cursor server-side não foi reproduzido no cluster de teste, só observado em produção após a troca, e uma das horas de dashboard ficou mais lenta.

Em 13 de maio de 2026, o CEVIU noticiou em "Amazon Redshift introduz instâncias RG baseadas em AWS Graviton com engine integrada para consultas em data lake" a promessa da AWS: desempenho até 2,2x mais rápido que o RA3 e custo 30% menor por vCPU. Agora há um caso de produção que confronta essa promessa. O corte de 30% no custo do cluster bate com o preço por vCPU anunciado, e os ganhos de consulta variaram de 2,1x a 5,2x nas tabelas pesadas, com a Halodoc medindo isso em sua própria carga, e não em benchmark.

Para quem opera Redshift em produção, o texto funciona como roteiro de validação: testar cada caminho real de dados, conferir que mascaramento e funções funcionam (e não só existem) e rever o concurrency scaling depois da troca. A economia veio em boa parte do uso menor de capacidade extra, algo que nem sempre aparece em comparação de preço por vCPU. Vale tratar os números como de uma carga específica, já que o resultado de outro warehouse pode variar.