Data warehouse para PME: necessário ou exagero?
Por Alexandre Pereira · · 4 min de leitura
A pergunta volta toda semana: minha empresa precisa de um data warehouse para PME ou estamos forçando infraestrutura de big tech onde não cabe? A resposta honesta — e que economiza dinheiro — é: até 5 milhões de registros e 10 fontes de dados, um banco relacional bem modelado (Postgres, MySQL) resolve. Acima disso, ou quando os sinais de gargalo aparecem, aí sim considere BigQuery ou Snowflake.
Uma distribuidora capixaba com 120 funcionários rodava dashboards no Metabase conectado direto no ERP TOTVS. Funcionou até cruzarem pedidos + estoque + forecast de vendas: query do painel passou de 2s para 18s. O ETL noturno, que antes levava 40 minutos, começou a demorar 3h20. Foi quando o data warehouse entrou na mesa — mas antes disso, o custo-benefício não fechava.
Por que até 5 milhões de registros Postgres basta?
Banco relacional moderno aguenta carga analítica se bem indexado e com particionamento de tabelas. Postgres 15+ com extensões como TimescaleDB (séries temporais) ou Citus (sharding horizontal) entrega desempenho suficiente para 90% das PMEs brasileiras. O segredo está na modelagem: normalização equilibrada, índices nos campos de filtro e agregação, vacuum automático configurado.
Uma rede varejista com 8 lojas em SP processava 3,2 milhões de transações/ano no Postgres hospedado no Supabase. Dashboard de vendas por hora/loja carregava em 1,4s. Custo mensal: R$ 780 (plano Pro). Migrar para BigQuery teria custado R$ 2.100/mês só de infraestrutura — sem contar retrabalho de queries SQL.
Outro ponto: bancos relacionais rodam em qualquer servidor. Data warehouse exige stack separada, pipeline de ingestão (Fivetran, Airbyte, n8n), orquestrador (Airflow, Prefect) e equipe que saiba modelar star schema. Para PME com 1-2 pessoas de dados, isso vira projeto de 4 meses.
Quando o data warehouse para PME faz sentido?
Dois sinais claros: query de dashboard demora mais de 5 segundos consistentemente (não pontual) e ETL noturno ultrapassa 3 horas. Nesses casos, o gargalo não é código — é arquitetura. Tentar otimizar índice a índice vira gambiarra cara.
Acima de 10 fontes de dados (ERP + CRM + e-commerce + marketplace + logística + financeiro + BI externo), a complexidade de manter JOINs entre sistemas diferentes corrói produtividade. BigQuery (free até 1TB de query/mês, depois US$ 5/TB) ou Snowflake (cobra por segundo de computação) entram como resposta técnica, não moda.
Uma indústria de embalagens com 180 funcionários cruzava 14 fontes: TOTVS Protheus, Bling, Mercado Livre, B2W, transportadoras (API), planilhas de produção, sensores IoT. Postgres travava em queries com 6+ JOINs. Migraram pra BigQuery: queries caíram de 22s pra 1,8s, ETL de 4h20 pra 38 minutos. Custo mensal subiu de R$ 890 (Postgres RDS) pra R$ 1.620 (BigQuery + Cloud Functions), mas liberou 12h/semana da equipe de dados.
Supabase como passo intermediário
Antes de pular pra solução enterprise, vale testar Supabase: Postgres gerenciado com API REST automática, autenticação embutida e edge functions. Plano Pro (R$ 780/mês) aguenta até 8GB de dados + 50GB de transferência. Se você já usa Postgres local e quer escalar sem reescrever tudo, é migração direta.
Quem precisa de mais potência pode partir pra PostgREST + TimescaleDB no mesmo Supabase, ganhando compressão de séries temporais (reduz storage em 40-60%) e queries agregadas 10x mais rápidas. Só quando isso não bastar — geralmente acima de 8-10 milhões de registros ou 15+ fontes — é que BigQuery ou Snowflake entram como próxima camada.
A decisão certa é: mantenha simples enquanto possível, migre quando as métricas (tempo de query, duração do ETL, custo de manutenção) provarem necessidade. Data warehouse para PME não é pecado — mas prematuridade de infra é desperdício de caixa.