Índice

• O que é OLAP (e o que não é)

  • O que OLAP não é
• OLAP vs OLTP: a diferença que explica tudo

  • Por que a orientação a colunas muda tudo
• A história: dos cubos ao colunar (e por que isso importa)

  • MOLAP, ROLAP, HOLAP
  • Por que o cubo morreu
  • O vocabulário que sobreviveu
• O esquema em estrela: como se modelam os dados OLAP
• Casos de uso práticos com SQL real

  • 1. Analítica de produto: funis de conversão
  • 2. Observabilidade: logs, métricas e traces
  • 3. Dashboards de e-commerce e BI
  • 4. Séries temporais e IoT
  • 5. Analítica voltada ao usuário (embedded analytics)
  • 6. Análise de retenção e coortes
• Os principais fornecedores de OLAP em 2026

  • Motores OLAP em tempo real (open source)
  • Data warehouses cloud gerenciados
  • Motores embutidos
  • Especializados
  • Motores de consulta sobre data lakes
  • E as camadas por cima
• Como escolher: meu critério em quatro perguntas
• Uma reflexão sobre por que isto importa mais do que parece
• Conclusão
• Perguntas frequentes

  • O que significa OLAP?
  • Qual é a diferença entre OLAP e OLTP?
  • PostgreSQL é um banco de dados OLAP?
  • Um cubo OLAP ainda é útil em 2026?
  • Cassandra é um banco de dados OLAP?
  • Posso usar OLAP num projeto pequeno?
  • Quanto custa um banco de dados OLAP?

O que é OLAP (e o que não é)

OLAP significa Online Analytical Processing, processamento analítico online. É uma categoria de carga de trabalho, não um produto concreto.

Essa distinção importa mais do que parece. Quando alguém diz "precisamos de uma OLAP", o que está descrevendo é um padrão: consultas que escaneiam e agregam de milhões a bilhões de linhas para responder perguntas de negócio. "Receita mensal por produto e região dos últimos três anos" é uma consulta OLAP tanto se você a executa no Excel contra um cubo de 1998 quanto se a lança contra uma tabela de um bilhão de linhas hoje.

O termo foi cunhado por E. F. Codd —o mesmo do modelo relacional— em um artigo de 1993 intitulado Providing OLAP to User-Analysts: An IT Mandate, onde definia doze regras para sistemas analíticos.

Uma nota honesta que quase ninguém menciona: aquele artigo era patrocinado pela Arbor Software, os fabricantes do Essbase, um dos primeiros produtos OLAP. As doze regras descreviam, de forma suspeitamente perfeita, o que o Essbase já fazia. Foi uma jogada de marketing brilhante disfarçada de paper acadêmico, e ainda assim a distinção de fundo que levantava —cargas analíticas precisam de um design diferente das transacionais— revelou-se completamente correta, e segue definindo o campo trinta anos depois.

A palavra "online" também confunde. Não tem nada a ver com internet: em 1993 significava interativo, em oposição aos relatórios em lote gerados à noite.

O que OLAP não é

Não é a mesma coisa que um data warehouse. OLAP é uma categoria de processamento; um data warehouse é um padrão de infraestrutura. Warehouses são construídos para servir cargas OLAP, mas OLAP também roda em bancos de dados em tempo real, motores embutidos e camadas semânticas.

Não são os bancos de dados "wide-column". Esse é um erro clássico e compreensível por causa do nome. Cassandra, HBase e Bigtable são descritos como "orientados a colunas", mas internamente são armazéns de linhas: agrupam linhas por chave de partição e guardam as colunas como pares chave-valor dentro de cada linha. Servem cargas OLTP com esquema flexível, não agregação analítica. Se alguém te propõe Cassandra para o seu dashboard, há um mal-entendido.

Não é sinônimo de "big data". Você pode ter uma carga OLAP perfeitamente legítima com 5 GB de dados. O padrão é definido pela forma das consultas, não pelo volume.

OLAP vs OLTP: a diferença que explica tudo

OLTP (Online Transaction Processing) é o que fazem PostgreSQL, MySQL ou Oracle: ler e escrever poucas linhas muito rápido, com transações e consistência forte. "Me dá o pedido 8821." "Desconte uma unidade do estoque."

OLAP é o oposto em quase todos os eixos:

	OLTP	OLAP
Armazenamento	Por linhas	Por colunas
Padrão de leitura	Poucas colunas, poucas linhas	Muitas linhas, poucas colunas
Padrão de escrita	Mutações de uma linha, alta frequência	Inserções em massa, quase só append
Latência alvo	Milissegundos	De sub-segundo a segundos
Concorrência	Milhares de usuários, consultas simples	Dezenas ou centenas, consultas complexas
Esquema	Normalizado (3NF)	Estrela ou desnormalizado largo
Pergunta típica	"Qual é o estado do pedido X?"	"Como evoluíram os pedidos por região?"
Exemplos	PostgreSQL, MySQL, Oracle	ClickHouse, Snowflake, BigQuery, DuckDB

Os dois designs são incompatíveis por natureza, e essa é a razão pela qual ambos existem. Um motor otimizado para escrever uma linha com integridade transacional não pode estar também otimizado para escanear quatrocentos milhões e reduzi-las a um número.

Por que a orientação a colunas muda tudo

A diferença física é simples de ver. Um banco de dados por linhas guarda isto no disco:

[id:1|país:ES|ingresos:42|fecha:...] [id:2|país:MX|ingresos:17|fecha:...]

Para somar ingresos você tem que ler também país, fecha e as outras trinta colunas que não te interessam. Um colunar guarda cada coluna separadamente:

ingresos: [42, 17, 88, 12, ...]
país:     [ES, MX, ES, AR, ...]

Se sua tabela tem 40 colunas e sua consulta usa 2, você lê 5% dos dados. E como valores contíguos são do mesmo tipo e tendem a se repetir, comprimem-se muito melhor: menos bytes no disco, menos I/O, consultas mais rápidas.

Além disso, motores modernos adicionam execução vetorizada (processar lotes de colunas com instruções SIMD em vez de linha a linha), data skipping (índices esparsos e estatísticas min/max para pular blocos inteiros sem lê-los) e separação de computação e armazenamento.

A história: dos cubos ao colunar (e por que isso importa)

Esta parte parece trivia de museu, mas explica por que a documentação que você encontra na internet está cheia de conceitos que ninguém usa mais.

MOLAP, ROLAP, HOLAP

Durante décadas, a taxonomia OLAP padrão foi esta:

Modelo	Armazenamento	Caminho de consulta	Força	Problema
MOLAP	Cubos pré-agregados (Essbase, Analysis Services)	MDX → consulta ao cubo	Respostas sub-segundo em dimensões predefinidas	Builds de horas; armazenamento explode ao adicionar dimensões; esquema rígido
ROLAP	Tabelas relacionais (Snowflake, BigQuery, ClickHouse)	SQL → agregação sob demanda	Consultas ad-hoc, dimensões arbitrárias, esquema flexível	Mais latência por consulta, exceto se o motor for muito rápido
HOLAP	Mistura de ambos	Cubo para resumos, SQL para o detalhe	Compromisso herdado dentro de stacks proprietários	Custo de operar dois sistemas

MOLAP foi o rei dos anos noventa e dois mil. A ideia do cubo OLAP era pré-calcular todas as agregações possíveis sobre dimensões hierárquicas (tempo, geografia, produto) para que consultar fosse uma busca em vez de um cálculo.

Funcionava, com dois custos brutais. O primeiro: os builds demoravam horas, então seus dados eram sempre de ontem. O segundo, mais insidioso: o cubo só respondia às perguntas previstas ao desenhá-lo. Se um analista quisesse cruzar duas dimensões que ninguém tinha antecipado, era preciso redesenhar e reconstruir o cubo. Semanas para responder a uma pergunta nova.

Por que o cubo morreu

A transição foi gradual. Sybase IQ lançou um motor colunar em 1994. Vertica, construída pelos autores do C-Store, saiu comercialmente em 2007. Google publicou o paper do Dremel —a base do BigQuery— em 2010. ClickHouse foi liberado como open source em 2016.

No final dos anos 2010 algo decisivo aconteceu: as latências que antes exigiam pré-agregar em um cubo já se conseguíam sobre os dados crus. Nesse momento a camada do cubo deixou de ser um benefício para se tornar fricção pura. Todo o custo (builds lentos, rigidez, um sistema a mais para operar) em troca de nada.

Os cubos não desapareceram totalmente: Essbase, Microsoft Analysis Services e MDX no Excel PowerPivot continuam vivos em grandes empresas. Mas para qualquer projeto novo a resposta é um motor colunar, e a pré-agregação, quando é necessária, resolve-se com vistas materializadas que se calculam de forma incremental e se consultam como uma tabela normal.

Minha opinião sobre por que isso importa mesmo que você nunca vá tocar num cubo: quando buscar informação sobre OLAP você vai encontrar muito material que dá como certo o paradigma MOLAP —falando de MDX, dimensões, builds— e que vai te levar a desenhar seu sistema com um modelo mental de 2003. A taxonomia sobrevive sobretudo em livros de texto e exames de certificação. Tome esses conceitos como história, não como guia.

O vocabulário que sobreviveu

Embora os cubos tenham morrido, a linguagem para falar de consultas analíticas segue a mesma. Traduzida para SQL moderno:

Roll-up (subir de nível de agregação): passar de vendas diárias a mensais.

SELECT toStartOfMonth(fecha) AS mes, sum(importe) AS ingresos
FROM ventas GROUP BY mes ORDER BY mes;

Drill-down (descer ao detalhe): do mês aos dias desse mês.

SELECT fecha, sum(importe) AS ingresos
FROM ventas WHERE toStartOfMonth(fecha) = '2026-07-01'
GROUP BY fecha ORDER BY fecha;

Slice (cortar uma dimensão com um valor fixo): só Espanha.

SELECT fecha, sum(importe) FROM ventas WHERE pais = 'ES' GROUP BY fecha;

Dice (subcubo com vários filtros): Espanha e México, categoria concreta, um trimestre.

SELECT pais, categoria, sum(importe)
FROM ventas
WHERE pais IN ('ES','MX') AND categoria = 'hardware'
  AND fecha BETWEEN '2026-04-01' AND '2026-06-30'
GROUP BY pais, categoria;

Pivot (girar linhas para colunas): no OLAP moderno são funções condicionais.

SELECT
    toStartOfMonth(fecha)         AS mes,
    sumIf(importe, pais = 'ES')   AS espana,
    sumIf(importe, pais = 'MX')   AS mexico,
    sumIf(importe, pais = 'AR')   AS argentina
FROM ventas GROUP BY mes ORDER BY mes;

Cinco conceitos que nos anos noventa requeriam um servidor dedicado e uma linguagem própria, e hoje são cinco consultas SQL.

O esquema em estrela: como se modelam os dados OLAP

O modelo lógico dominante em analítica é o esquema em estrela: uma tabela de fatos no centro, rodeada de tabelas de dimensões.

A tabela de fatos contém os eventos mensuráveis, com muitas linhas e poucas colunas: uma venda, um clique, uma leitura de sensor. As tabelas de dimensões contêm o contexto descritivo: quem é esse cliente, qual categoria tem esse produto, em qual região está essa loja.

-- Tabela de fatos: cresce sem parar
CREATE TABLE hechos_ventas (
    fecha       Date,
    producto_id UInt32,
    cliente_id  UInt32,
    tienda_id   UInt16,
    unidades    UInt32,
    importe     Decimal(12, 2)
) ENGINE = MergeTree
ORDER BY (tienda_id, fecha, producto_id);

-- Dimensão: pequena e estável
CREATE TABLE dim_producto (
    producto_id UInt32,
    nombre      String,
    categoria   LowCardinality(String),
    marca       LowCardinality(String)
) ENGINE = MergeTree ORDER BY producto_id;

Há aqui um matiz que separa a teoria da prática. Num data warehouse clássico, o esquema em estrela é dogma. Nos motores OLAP colunares modernos, muitas vezes convém desnormalizar e colocar categoria e marca diretamente na tabela de fatos. Soa a heresia —estás duplicando dados— mas como essas colunas se comprimem brutalmente bem com LowCardinality, o custo de armazenamento é quase nulo e poupa-se um JOIN em cada consulta.

Minha regra: comece desnormalizando o que quase nunca muda (categoria do produto, país da loja) e mantenha como dimensão separada o que muda com frequência ou o que é grande.

Casos de uso práticos com SQL real

É aqui que OLAP deixa de ser teoria. Estes são os padrões que você de fato vai encontrar.

1. Analítica de produto: funis de conversão

O caso mais comum em produto. Você quer saber quanta gente passa de ver uma página a registrar-se e daí a comprar, e onde caem.

Em SQL padrão isso é um pesadelo de CTEs e self-joins. Num motor OLAP moderno é uma função:

SELECT nivel, count() AS usuarios
FROM (
    SELECT
        usuario_id,
        windowFunnel(86400)(
            timestamp,
            evento = 'pageview',
            evento = 'signup',
            evento = 'purchase'
        ) AS nivel
    FROM eventos
    WHERE fecha >= today() - 30
    GROUP BY usuario_id
)
GROUP BY nivel
ORDER BY nivel;

windowFunnel(86400) conta quantos passos consecutivos cada usuário completou dentro de uma janela de 24 horas. O resultado te dá diretamente a forma do funil.

Por que você precisa de OLAP aqui: esta consulta toca todos os eventos de todos os usuários de um mês. Em Postgres com dezenas de milhões de linhas, é um escaneamento sequencial que derruba o banco de produção.

2. Observabilidade: logs, métricas e traces

Logs são o caso OLAP por excelência e muita gente não vê porque os associa ao Elasticsearch. São eventos com marca de tempo, escrevem-se muito, leem-se por agregação e quase nunca se atualizam.

SELECT
    toStartOfMinute(timestamp)                    AS minuto,
    servicio,
    count()                                       AS total,
    countIf(nivel = 'ERROR')                      AS errores,
    round(countIf(nivel = 'ERROR') / count(), 4)  AS tasa_error,
    quantile(0.95)(duracion_ms)                   AS p95,
    quantile(0.99)(duracion_ms)                   AS p99
FROM logs
WHERE timestamp >= now() - INTERVAL 3 HOUR
GROUP BY minuto, servicio
HAVING tasa_error > 0.01
ORDER BY minuto DESC;

Percentis, taxas de erro e agrupamento por minuto numa única passada. Adicione um TTL para que os dados com mais de 90 dias se apaguem sozinhos e você tem uma plataforma de observabilidade completa.

Nota econômica que mudou minhas contas: migrar logs de uma solução SaaS de observabilidade para um banco OLAP autoalojado é uma das maiores reduções de custo disponíveis para um projeto pequeno. Os preços das plataformas de logs calculam-se por volume ingerido, e o volume de logs só cresce.

3. Dashboards de e-commerce e BI

O caso clássico: métricas de negócio agregadas por múltiplas dimensões.

SELECT
    toStartOfWeek(fecha)                       AS semana,
    categoria,
    sum(importe)                               AS ingresos,
    count()                                    AS pedidos,
    uniq(cliente_id)                           AS clientes,
    round(sum(importe) / count(), 2)           AS ticket_medio,
    round(sum(importe) / uniq(cliente_id), 2)  AS ingreso_por_cliente
FROM hechos_ventas
WHERE fecha >= today() - 180
GROUP BY semana, categoria
ORDER BY semana DESC, ingresos DESC;

Repare em uniq(): usa HyperLogLog para contar distintos de forma aproximada, com um erro típico abaixo de 1% e um consumo de memória ridículo comparado com uniqExact(). Para um dashboard de negócio, essa aproximação é perfeitamente aceitável e a diferença de desempenho é enorme.

4. Séries temporais e IoT

Sensores, métricas de infraestrutura, preços de mercado. Dados que chegam a muita frequência e se consultam a uma resolução menor.

SELECT
    toStartOfFifteenMinutes(timestamp)  AS intervalo,
    sensor_id,
    round(avg(temperatura), 2)          AS media,
    min(temperatura)                    AS minima,
    max(temperatura)                    AS maxima,
    count()                             AS lecturas
FROM metricas_sensores
WHERE timestamp >= now() - INTERVAL 7 DAY
  AND sensor_id IN (101, 102, 103)
GROUP BY intervalo, sensor_id
ORDER BY intervalo;

O padrão que torna isso sustentável é a redução progressiva de resolução: você guarda leituras por segundo durante uma semana, por hora durante um ano e por dia indefinidamente. Com um TTL agregador, isto é automático.

5. Analítica voltada ao usuário (embedded analytics)

O caso mais exigente. Não é um dashboard interno que três pessoas olham: é uma aba de "Estatísticas" dentro do seu produto que todos os seus clientes consultam ao mesmo tempo.

SELECT
    toDate(timestamp)     AS dia,
    count()               AS visitas,
    uniq(visitante_id)    AS visitantes,
    countIf(rebote)       AS rebotes
FROM eventos_web
WHERE tenant_id = {tenant:UInt32}      -- sempre primeiro no ORDER BY!
  AND timestamp >= {desde:DateTime}
GROUP BY dia
ORDER BY dia;

Aqui a chave do design é que tenant_id seja a primeira coluna da chave de ordenação. Assim cada cliente só escaneia seus próprios dados, e a latência mantém-se em milissegundos embora a tabela tenha bilhões de linhas de todos os clientes juntos. É a diferença entre uma funcionalidade que escala e uma que cai quando chegam cem clientes.

6. Análise de retenção e coortes

Quantos usuários que se registraram num mês seguem ativos meses depois.

SELECT
    cohorte,
    mes_relativo,
    uniq(usuario_id) AS usuarios
FROM (
    SELECT
        usuario_id,
        fecha,
        toStartOfMonth(min(fecha) OVER (PARTITION BY usuario_id)) AS cohorte,
        dateDiff('month', cohorte, toStartOfMonth(fecha))         AS mes_relativo
    FROM eventos
)
GROUP BY cohorte, mes_relativo
ORDER BY cohorte, mes_relativo;

Cuidado com onde coloca o OVER: tem que ir grudado em min(fecha), dentro de toStartOfMonth(). Se você escreve toStartOfMonth(min(fecha)) OVER (...), ClickHouse interpreta que toStartOfMonth é a função de janela e falha com Aggregate function with name 'toStartOfMonth' does not exist.

Esse tipo de consulta —janelas sobre toda a tabela— é exatamente o que afunda um banco transacional e o que um colunar resolve num par de segundos.

Os principais fornecedores de OLAP em 2026

O mercado divide-se em cinco categorias bastante nítidas. Ordeno-as por como encaixam em projetos reais, não por cota de mercado.

Motores OLAP em tempo real (open source)

Latência sub-segundo, ingestão contínua, pensados para dashboards ao vivo e analítica embutida.

ClickHouse é a referência da categoria. Colunar, um só binário, licença Apache 2.0, escala de um portátil a centenas de nós. É a opção por padrão para self-hosting e tem serviço gerenciado próprio (ClickHouse Cloud). Se quiser o detalhe, tenho um guia completo de ClickHouse.

Apache Druid leva anos fazendo analítica de séries temporais em tempo real em grande escala. Muito potente para ingestão desde Kafka, mas com um custo operacional alto: seis tipos de processo mais ZooKeeper.

Apache Pinot nasceu no LinkedIn para servir analítica a centenas de milhões de usuários. É o mais especificamente desenhado para latência mínima com concorrência muito alta, com a mesma pega de complexidade operativa.

StarRocks e Apache Doris são primos próximos, com MPP colunar e um otimizador de JOINs mais forte que o do ClickHouse. Boa escolha se seu esquema é um warehouse normalizado.

Data warehouses cloud gerenciados

Zero operações, escala praticamente ilimitada, faturação por consumo.

Snowflake popularizou a separação de computação e armazenamento e domina o segmento empresarial. Muito maduro em governação de dados e permissões. Cobra por tempo de computação do warehouse.

Google BigQuery é serverless de verdade: você não gerencia cluster, escreve SQL. Cobra principalmente por dados escaneados, o que faz com que consultas mal escritas saiam caras.

Amazon Redshift é a opção do ecossistema AWS. Mais antigo, requer mais tuning manual, mas integra-se de forma nativa com o resto dos serviços da Amazon.

Databricks SQL é a referência da arquitetura lakehouse, unindo engenharia de dados, machine learning e analítica sobre o mesmo armazenamento. Forte quando há dados não estruturados e fluxos de IA em jogo.

Azure Synapse completa o trio de hiperscalers para quem já vive na Microsoft.

Meu aviso sobre esta categoria, repetido da comparativa mas relevante aqui: o modelo de preço por consumo pune justamente o padrão da analítica interativa, muitas consultas pequenas e frequentes. Um dashboard com auto-refresh pode gerar uma fatura desproporcional. Se trabalha com orçamento apertado, a fatura variável é um risco de negócio, não só técnico.

Motores embutidos

Sem servidor, correm dentro do seu processo.

DuckDB é SQLite para analítica: pip install duckdb e já tens um motor colunar vetorizado com dialeto compatível com PostgreSQL. Lê Parquet e CSV diretamente. Para datasets que cabem numa máquina, é imbatível em simplicidade. MotherDuck é sua camada cloud.

chDB é o motor de ClickHouse embutido em Python, com API estilo pandas.

Especializados

kdb+ domina o trading de alta frequência. Extremamente rápido em séries temporais, com uma linguagem própria (q) e um preço à altura de seu nicho.

QuestDB é open source e orientado a séries temporais com SQL estendido.

TimescaleDB —da empresa que em 2025 passou a chamar-se TigerData, embora a extensão open source mantenha o nome— converte PostgreSQL num banco de séries temporais. Se já usa Postgres e seu volume é moderado, é a migração de menor fricção possível.

Firebolt e SingleStore competem no nicho de desempenho alto com gestão cloud.

Motores de consulta sobre data lakes

Trino (antes PrestoSQL) e Apache Spark SQL consultam dados que vivem em formatos abertos como Apache Iceberg, Delta Lake ou Parquet sobre armazenamento de objetos. Não são bancos de dados: são motores que colocam SQL sobre seus arquivos.

Esta categoria está a borrar a fronteira entre "data lake" e "banco de dados OLAP". Muitos motores colunares —ClickHouse entre eles— já leem Iceberg e Parquet diretamente, o que significa que pode consultar seu lago sem ingerir nada.

E as camadas por cima

Vale a pena mencionar que OLAP é a camada de processamento, não a de apresentação. Tableau, Looker, Power BI, Metabase e Grafana são ferramentas de BI que se conectam a um banco OLAP para executar as consultas por baixo. O banco põe velocidade e estrutura; o BI põe a interface.

Como escolher: meu critério em quatro perguntas

Traduzido em decisões práticas.

Seus dados cabem numa máquina (digamos, menos de algumas centenas de GB)? Comece por DuckDB. Zero operações, desempenho excelente e SQL familiar. É a recomendação que mais gente ignora e a que mais vezes resulta correta.

Precisa de um serviço compartilhado com escrituras contínuas e vários leitores? ClickHouse. É o melhor ponto de equilíbrio entre desempenho e complexidade operativa que existe hoje, e funciona num VPS modesto.

Já vive em PostgreSQL e seu volume é moderado? TimescaleDB. Acrescenta uma extensão em vez de um serviço novo. A opção aborrecida costuma ser a correta.

Tem equipe, orçamento e prioridade em zero infraestrutura? Snowflake, BigQuery ou Databricks. Configure alertas de custo no primeiro dia.

E a pergunta prévia a todas: você realmente precisa de OLAP? Se sua maior tabela tem dois milhões de linhas e suas consultas demoram 200 ms em Postgres, a resposta é não. Acrescentar um sistema analítico é acrescentar um serviço para manter, fazer backup e monitorizar. O sinal de que chegou o momento é concreto: quando uma agregação central para seu produto demora mais de cinco segundos e você já tentou indexá-la.

Uma reflexão sobre por que isto importa mais do que parece

Durante anos achei que "OLAP" era jargão corporativo para gente que trabalha com cubos em bancos. É um preconceito bastante estendido entre desenvolvedores, e custou-me caro.

O que me fez mudar de opinião foi perceber que quase todo produto digital gera dados de eventos, e quase nenhum os aproveita porque a infraestrutura por padrão —um banco relacional— faz que consultá-los seja doloroso. Assim acabam descartados, ou guardados numa tabela que ninguém se atreve a tocar, ou paga-se um SaaS de analítica que lhe dá 10% do que poderia ter.

Adotar um banco OLAP não mudou o que eu podia medir. Mudou a frequência com que perguntava. Quando uma consulta demora 40 segundos, explora duas hipóteses por sessão. Quando demora 300 milissegundos, explora vinte. E essa diferença de frequência é a que acaba produzindo achados que você não buscava.

Esse é o argumento real a favor de OLAP, e não aparece em nenhum benchmark: não é que as consultas vão mais rápido, é que você faz mais perguntas.

Conclusão

OLAP não é uma tecnologia concreta nem uma moda: é a categoria de sistemas construídos para responder perguntas sobre grandes volumes de dados, e leva trinta anos existindo sob diferentes nomes. O que mudou radicalmente é a implementação: de cubos rígidos que se construíam de noite a motores colunares que agregam sobre dados crus em milissegundos.

Para um projeto pequeno hoje, essa evolução significa algo muito concreto: capacidades analíticas que em 2005 requeriam uma equipe dedicada e uma licença de seis dígitos hoje cabem num binário que corre num VPS de vinte euros por mês.

Se quer passar da teoria a algo funcionando, o caminho mais curto é:

• O que é ClickHouse e como instalá-lo — de zero a consultas reais em cinco minutos.
• Alternativas a ClickHouse: comparativa — para escolher com critério entre as opções deste post.
• Guia avançada de otimização — vistas materializadas, projections, codecs e TTL.

---

Perguntas frequentes

O que significa OLAP?

Online Analytical Processing. Designa uma categoria de cargas de trabalho analíticas —agregações e agrupamentos sobre milhões de linhas— e os sistemas construídos para servi-las. O termo foi cunhado por E. F. Codd em 1993, e "online" significa interativo, não relacionado com internet.

Qual é a diferença entre OLAP e OLTP?

OLTP é orientado a linhas e otimizado para ler e escrever poucos registros com latência de milissegundos. OLAP é orientado a colunas e otimizado para escanear e agregar milhões de linhas. Seus designs são opostos, por isso coexistem na mesma arquitetura em vez de se substituírem.

PostgreSQL é um banco de dados OLAP?

Não. PostgreSQL é OLTP: seu armazenamento por linhas e seus índices B-tree são pensados para buscas pontuais e escritas pequenas. Extensões como TimescaleDB, Citus ou pg_duckdb acrescentam capacidade analítica limitada, mas em escala o padrão é Postgres para escritas mais um banco OLAP para leituras, conectados por CDC.

Um cubo OLAP ainda é útil em 2026?

Só em ambientes herdados. Motores colunares conseguem latências equivalentes calculando as agregações sob demanda, e quando é preciso pré-agregar usam-se vistas materializadas incrementais em vez de cubos.

Cassandra é um banco de dados OLAP?

Não. Cassandra, HBase e Bigtable são armazéns "wide-column" mas orientados a linhas no nível de armazenamento. Servem cargas OLTP com esquema flexível, não agregação analítica.

Posso usar OLAP num projeto pequeno?

Sim, e cada vez é mais fácil. DuckDB corre como biblioteca dentro da sua aplicação e ClickHouse como um único binário num VPS. Já não é preciso infraestrutura empresarial para começar.

Quanto custa um banco de dados OLAP?

As opções open source autoalojadas (ClickHouse, DuckDB, StarRocks) não têm custo de licença; você paga o servidor e seu tempo de operação. Os serviços gerenciados cobram por computação e armazenamento, com modelos que variam muito: BigQuery cobra sobretudo por dados escaneados e Snowflake por tempo de computação ativo.