- Data warehouse não é exclusividade de grandes corporações — PMEs com mais de uma fonte de dados e demanda por relatórios confiáveis já justificam a adoção.
- A escolha da tecnologia errada é o erro mais caro: over-engineering superdimensionado ou under-engineering que cria limitações em 12 meses.
- O modelo de custo do warehouse moderno é fundamentalmente diferente do modelo legado — entender essa diferença é pré-requisito para escolher certo.
Data warehouse não é mais coisa de grande empresa
Por muito tempo, data warehouses eram projetos de TI de grandes corporações — custosos, demorados e exigiam time dedicado para manter. O Teradata clássico de uma grande varejista nacional custava seis dígitos por ano só em licença. Uma PME com 200 colaboradores simplesmente não tinha acesso a essa tecnologia.
O cloud computing mudou isso completamente. Hoje, uma startup com R$ 500/mês pode ter um data warehouse com as mesmas capacidades técnicas do que organizações gastavam R$ 500.000/ano. A barreira de entrada caiu de forma drástica — mas a barreira de conhecimento para escolher e implementar corretamente permanece.
Este guia endereça exatamente isso: o que considerar, o que evitar e como implementar um warehouse que entregue valor real para uma PME.
O que é um data warehouse moderno (e o que não é)
Um data warehouse é um sistema de armazenamento de dados otimizado para consultas analíticas — leituras que agregam grandes volumes de dados históricos para responder perguntas de negócio.
Diferente de um banco de dados transacional (MySQL, PostgreSQL, SQL Server), o warehouse não foi projetado para processar milhares de transações por segundo, mas para responder perguntas como "qual foi a margem por linha de produto nos últimos 18 meses, por região, com variação mês a mês?".
O que um warehouse moderno faz bem: armazenar dados históricos de múltiplas fontes; executar queries analíticas complexas sobre bilhões de linhas; separar armazenamento de capacidade de processamento (escalabilidade independente); integrar com ferramentas de BI e dbt para transformação de dados.
O que um warehouse não faz: substituir seu banco de dados transacional (o ERP continua no PostgreSQL); processar eventos em tempo real com latência de milissegundos (para isso existe streaming); servir como sistema de backup.
A confusão mais comum é usar o warehouse como "banco de dados de tudo" — armazenar dados operacionais e analíticos no mesmo lugar. Isso gera custos desnecessários e degrada a performance para as queries que importam.
Quando uma PME realmente precisa de um warehouse
Nem toda PME precisa de um data warehouse. Há três condições que, juntas, justificam o investimento:
Condição 1 — Múltiplas fontes de dados: quando a empresa tem dados relevantes em mais de dois sistemas distintos (ERP, CRM, plataforma de marketing, e-commerce, suporte), consolidar essas fontes em consultas manuais torna-se inviável.
Condição 2 — Histórico é importante: quando decisões de negócio dependem de análise temporal — tendências, sazonalidade, cohort analysis, comparação ano a ano — o banco transacional não foi projetado para essas queries. Um warehouse com dados históricos de 2-3 anos muda a qualidade das análises.
Condição 3 — Múltiplos consumidores de dados: quando mais de 3-5 pessoas na empresa precisam acessar dados para tomar decisões (e não só o analista que "faz os relatórios"), um warehouse com ferramenta de BI conectada democratiza o acesso sem criar dependência de uma pessoa.
Se apenas uma ou duas dessas condições se aplicam, um banco de dados PostgreSQL bem modelado com views materializadas pode ser suficiente por mais tempo.
Data warehouse vs. data lake vs. data lakehouse
Esses termos são usados com frequência — e frequentemente de forma intercambiável incorreta. A distinção importa para a decisão de arquitetura:
Data warehouse: armazena dados estruturados (tabelas, schemas definidos), otimizado para SQL analítico. Alta governança, alta confiabilidade, ideal para relatórios e dashboards. Exemplos: BigQuery, Snowflake, Redshift.
Data lake: armazena dados em qualquer formato (structured, semi-structured, unstructured) em armazenamento de objeto barato (S3, GCS). Alta flexibilidade, governança difícil se não bem gerenciado. Ideal para armazenar dados brutos antes de saber como usá-los.
Data lakehouse: arquitetura que combina o baixo custo e flexibilidade do data lake com a governança e performance do warehouse. Formatos como Delta Lake, Apache Iceberg e Apache Hudi habilitam isso. Exemplos de plataformas: Databricks, BigLake, AWS Lake Formation.
Para PMEs, a recomendação é direta: comece com um data warehouse. A simplicidade operacional e a governança nativa são mais valiosas do que a flexibilidade de um lake quando a equipe técnica é pequena. Evoluir para um lakehouse é possível quando o volume e a variedade de dados justificarem.
Comparativo: BigQuery, Snowflake, Redshift e DuckDB
| Critério | BigQuery (Google) | Snowflake | Redshift (AWS) | DuckDB |
|---|---|---|---|---|
| Modelo de custo | Pay-per-query + storage | Créditos (compute + storage) | Instância reservada ou serverless | Gratuito (open-source) |
| Free tier | Sim (10 GB + 1 TB query/mês) | Trial de 30 dias | Não (apenas Free Tier AWS) | Gratuito sempre |
| Escalabilidade | Automática e ilimitada | Automática com virtual warehouses | Manual ou serverless | Limitada ao hardware local |
| SQL padrão | BigQuery SQL (ANSI + extensões) | ANSI SQL completo | PostgreSQL-like | DuckDB SQL (ANSI + extensões) |
| Integração BI | Nativa com Looker Studio; conector Power BI | Conectores para todos os principais | Conectores para todos os principais | Conectores via ODBC/API |
| Melhor para | PMEs e startups; ecossistema Google | Multi-cloud; times com SQL avançado | Empresas já no ecossistema AWS | Análise local; volumes < 100 GB |
| Custo mensal típico (PME) | R$ 0 – R$ 800 | R$ 500 – R$ 2.500 | R$ 400 – R$ 3.000 | R$ 0 |
Modelo de custo e como evitar surpresas na fatura
O modelo de custo do warehouse moderno é radicalmente diferente do modelo legado. Entender isso evita as surpresas mais comuns:
BigQuery: cobra por dado processado em query (R$ ~25/TB no Brasil). Uma query mal escrita que faz full scan de uma tabela de 500 GB custa R$ 12,50. Boas práticas — particionar tabelas, usar clustering, aplicar filtros nas colunas particionadas — reduzem custos em 90%+ para workloads típicos.
Snowflake: cobra por compute (créditos consumidos enquanto o virtual warehouse está rodando) + storage. Um virtual warehouse XS consome 1 crédito/hora. O risco é deixar warehouses ligados sem uso — implementar auto-suspend (timeout de 60-120 segundos) é obrigatório.
Redshift Serverless: cobra por RPU-hora (unidade de compute). O modelo serverless elimina instâncias reservadas, mas requer definição de RPU máximos para evitar custos explosivos em queries mal otimizadas.
Controle de custo universal: implementar alertas de billing no provedor de nuvem; definir cotas de query para usuários de negócio; usar tabelas materializadas para queries frequentes e pesadas; monitorar o custo por query no history logs.
Roadmap de implementação em 6 etapas
Listar as 10 perguntas mais importantes que o negócio precisa responder com dados. Isso define o escopo do modelo de dados e evita construir infraestrutura sem uso.
Inventariar todas as fontes de dados relevantes e selecionar a plataforma de warehouse com base no ecossistema atual da empresa e no modelo de custo mais adequado ao perfil de uso.
Projetar as tabelas dimensionais e fatos (modelo estrela ou snowflake) para as perguntas prioritárias. Documentar o dicionário de dados antes de criar qualquer tabela.
Implementar os conectores das fontes para o warehouse (Airbyte, Fivetran, scripts Python). Definir frequência de atualização e strategy de carregamento (full load vs. incremental).
Usar dbt para transformar dados brutos em modelos de negócio documentados, testados e versionados. Essa camada é o coração da confiabilidade dos dados.
Conectar Power BI, Metabase ou Looker Studio ao warehouse, criar os dashboards prioritários e treinar os usuários de negócio. Medir adoção e iterar.