Casos de uso típicos
Três cenários onde a combinação de CDC contínuo e StarRocks resolve um problema concreto que outras arquiteturas resolvem mal. e um quarto cenário onde nada disso é necessário e Postgres puro continua sendo a melhor escolha.
SaaS B2B multi-tenant com dashboards por cliente
Sintoma: a aplicação multi-tenant cresceu, cada cliente tem um dashboard com KPIs em "tempo real", e as queries do BI começaram a competir com as queries da aplicação no mesmo Postgres. O time tentou usar uma read replica, mas a replica continua sendo Postgres. JOINs analíticos cruzando 5 ou 6 tabelas grandes ainda demoram dezenas de segundos, alguns travam com timeout.
O que muda com o datalake: as tabelas que alimentam dashboards (eventos, transações, contas, assinaturas) são replicadas continuamente para o StarRocks. As queries do dashboard passam a apontar para o datalake, com latência de poucos segundos por query, e o Postgres recupera a capacidade que estava sendo consumida pelo BI. O isolamento por tenant é mantido (filtros por tenant_id), e materialized views podem pré-agregar os KPIs mais consultados.
Dashboards que antes demoravam 15-30s por carga passam a abrir em 1-3s. O Postgres deixa de ser o gargalo do produto. Custo de infra cai: o StarRocks roda em uma única VM modesta e dispensa upgrades verticais sucessivos no banco principal.
E-commerce e retail: produtos × pedidos × eventos
Sintoma: a operação tem o catálogo num banco, os pedidos em outro, os eventos do site (cliques, carrinhos) em uma terceira fonte, e quer responder perguntas como "qual a conversão de carrinho por categoria de produto, segmentada por canal de aquisição, na última hora". Hoje isso não acontece em tempo real. passa por um ETL diário que entrega o número D-1.
O que muda com o datalake: as três origens convergem para o StarRocks. Cruzamentos de produto × pedido × evento ficam em uma única query SQL, sem mover dados manualmente. A latência das tabelas críticas (carrinho, pedido) cai de D-1 para uma janela típica de 15 segundos a 2 minutos, então a resposta da pergunta acima passa a ser viável "agora" e não "amanhã". O time de produto consegue rodar AB tests com decisão no mesmo dia em vez de esperar uma semana.
Time de growth deixa de operar com dados de ontem. Decisões de campanha, de pricing dinâmico ou de remarketing acontecem em janelas operacionais reais. Os relatórios fiscais e financeiros, que antes esperavam o ETL, podem ser gerados a qualquer momento.
Auditoria e compliance LGPD com histórico imutável
Sintoma: a operação precisa responder a perguntas de auditoria do tipo "como esse cadastro estava em 12/03 às 14h?" ou "quem fez quais alterações neste registro nos últimos 90 dias?". O Postgres operacional sobrescreve o estado anterior; reconstruir o histórico depende de logs aplicacionais que nem sempre existem, ou de backups que precisam ser restaurados em ambientes paralelos.
O que muda com o datalake: cada alteração capturada pelo CDC é registrada no datalake com timestamp e operação (insert, update, soft delete). O estado de qualquer registro em qualquer ponto do tempo passa a ser uma query SQL: SELECT * FROM tbl WHERE id = ? AND _commit_ts <= '2025-03-12 14:00' ORDER BY _commit_ts DESC LIMIT 1. Soft delete preserva linhas removidas com _deleted_at. nada some por engano.
Resposta a solicitações de titular de dados (LGPD), auditorias regulatórias e investigações internas deixa de ser um projeto de engenharia e vira uma query. Em setores regulados (financeiro, saúde, seguros) isso reduz risco operacional concreto.
Quando o datalake é overkill
Vale a transparência: não recomendamos o serviço quando ele não vai entregar valor proporcional ao esforço. Os sinais clássicos:
- Volume pequeno. Se a tabela analítica mais pesada cabe em poucas dezenas de milhares de linhas e as queries rodam em menos de 1s no Postgres, manter Postgres puro é o mais sensato. Adicionar CDC e StarRocks aqui é complexidade sem retorno.
- Necessidade de transações ACID no datalake. StarRocks é um motor analítico (OLAP), não transacional (OLTP). Não substitui o Postgres operacional. complementa. Se o requisito é escrever no datalake e ter garantias de transação, a arquitetura é outra.
- Apenas dois ou três relatórios estáticos. Se a operação precisa de relatórios gerados uma vez por mês com baixa latência aceitável, dump + scripts SQL ad-hoc costumam resolver a um custo muito menor.
- Sem autonomia para alterar pequenas configurações no Postgres. O CDC requer permissão para configurar replicação lógica (
wal_level=logical, criação de slot e publication). Se a operação está em um banco gerenciado sem essas permissões, é preciso resolver isso antes. em alguns casos, não compensa.
Em uma primeira conversa avaliamos honestamente se o caso é um dos três cenários acima. ou um dos quatro abaixo. Não vendemos o que não vai entregar.
Avaliar para o seu cenário
Descreva o caso em poucas linhas: quais bancos, quais consultas, qual frescor de dado é necessário. Em uma primeira reunião, projetamos números específicos.