Data warehouse para PME: necessário ou exagero?
Por Alexandre Pereira · · 4 min de leitura
Você abre o dashboard de vendas, clica em "últimos 90 dias" e… espera. 8 segundos de loading. Alguém do time de TI comenta que o ETL da madrugada travou de novo — já são 4 horas rodando, deveria levar 40 minutos. Aparece a sugestão: "precisamos de um data warehouse". Mas será?
A resposta honesta: se a empresa tem até 5 milhões de registros e consulta até 10 fontes diferentes (ERP, CRM, planilha de vendas, base de cliente), um banco relacional bem modelado — Postgres, por exemplo — dá conta de 90% do trabalho. Data warehouse para PME não é a primeira resposta; é a terceira ou quarta, quando sinais claros aparecem.
Quando o banco relacional começa a travar?
Dois sinais objetivos mostram que o problema não é só "otimizar melhor". Primeiro: query do dashboard demora mais de 5 segundos mesmo com índice criado e tabela enxuta. Segundo: o ETL — aquele script que roda de madrugada pra consolidar dados — leva 3 horas ou mais e já travou 2 vezes no mês.
Uma distribuidora capixaba com 180 funcionários chegou nesse ponto depois de 6 anos: 8,2 milhões de linhas de pedido, cruzando estoque de 14 filiais, histórico de preço e tabela de cliente. O Postgres começou a derrapar — queries de 12s, ETL de 5h. Aí sim fez sentido migrar parte analítica pra BigQuery. Mas até 5M registros? Ela rodava no Postgres sem esforço.
Um caminho intermediário é usar Supabase (Postgres gerenciado + API instantânea). Ele escala até uns 20M registros sem drama, custa menos que montar infraestrutura própria e já entrega autenticação e storage junto. Serve como ponte: quando crescer demais, você exporta histórico pra BigQuery ou Snowflake e mantém só dado recente no Supabase.
Quanto custa um data warehouse de verdade?
BigQuery cobra por query rodada (free até 1TB processado por mês — coisa que PME raramente estoura). Se você roda 200GB de consulta mensal, paga zero. Passa disso, sai uns US$ 5 por TB. Snowflake tem modelo parecido, mas cobra storage separado — geralmente sai R$ 600-1.200/mês pra base de 500GB com consulta moderada.
O problema não é a licença; é a engenharia. Modelar warehouse direito (star schema, tabelas de dimensão, particionamento) leva 6-10 semanas de um engenheiro de dados. Se a empresa não tem esse perfil no time, vai contratar consultoria — R$ 18-35k o projeto. Some manutenção: toda vez que o ERP muda campo, alguém precisa ajustar o pipeline.
Uma indústria de móveis do sul de Minas com 95 pessoas tentou montar warehouse antes da hora: gastou R$ 42k em 4 meses, rodou 2 dashboards e descobriu que 80% das consultas ainda vinham de Excel exportado do ERP. Resultado: desligaram o warehouse, voltaram pro Postgres bem indexado e investiram numa API que alimenta Power BI direto do banco transacional. Resolveu, custou 1/5 do preço.
O que fazer antes de partir pro warehouse
Antes de gastar com Snowflake, teste 3 coisas. Primeiro: normalize o banco — tire coluna repetida, crie índice nas foreign keys, rode VACUUM no Postgres. Segundo: separe leitura de escrita — réplica read-only pro dashboard, banco principal só pra transação. Terceiro: rode ETL incremental (só linha nova) ao invés de reprocessar tudo toda noite.
Em 70% dos casos, esses 3 passos cortam o tempo de query pela metade e o ETL de 3h cai pra 35 minutos. Se ainda assim a coisa trava — dashboard > 5s, ETL > 3h, mais de 10 fontes diferentes, histórico batendo 8M+ registros —, aí sim considere BigQuery ou Snowflake. Comece exportando só o histórico antigo (> 2 anos) pro warehouse e mantenha dado recente no Postgres. Isso já alivia 60-70% da carga.
Quem está nesse momento pode rodar um diagnóstico de 2 semanas: mapeie quantas linhas tem em cada tabela, quanto tempo leva cada query do dashboard, se o gargalo é join ou volume bruto. Daí fica claro: otimizar o que já existe ou partir pra camada analítica separada.