DuckDB, ClickHouse, Druid ou Pinot: como escolher o OLAP

DuckDB, ClickHouse, Druid e Pinot resolvem problemas diferentes. Árvore de decisão e tabela comparativa para escolher o motor OLAP certo para o seu caso de uso.

Índice

Não é um ranking, é uma árvore de decisão
A tabela comparativa
DuckDB: quando você não precisa de um serviço
ClickHouse: o ponto de equilíbrio para produção
Druid e Pinot: quando você de fato precisa de tempo real em escala massiva
Casos reais mapeados
Perguntas frequentes
Conclusão

Não é um ranking, é uma árvore de decisão

A razão pela qual as comparativas genéricas de "DuckDB vs ClickHouse vs Druid vs Pinot" costumam confundir mais do que esclarecer é que misturam duas perguntas distintas como se fossem uma só:

Pergunta 1: você precisa de um serviço, ou basta uma biblioteca? O DuckDB roda dentro do seu processo. Os outros três são serviços que você sobe à parte, com portas, usuários e alta disponibilidade no meio.

Pergunta 2: se você precisa de um serviço, qual é a sua prioridade, a analítica de propósito geral ou a latência sob concorrência extrema? O ClickHouse está otimizado para a primeira. Druid e Pinot nasceram para a segunda.

Com essas duas perguntas respondidas, a árvore fica assim:

As suas consultas são lançadas por um único processo —seu backend, um notebook, um script de ETL— e os dados cabem folgados em um disco? → DuckDB. Você não precisa de mais nada.
Você precisa de um serviço compartilhado, com escritas contínuas de várias fontes, e a sua carga é "agregações sobre uma tabela de eventos que cresce"? → ClickHouse. É o ponto de equilíbrio para a imensa maioria dos projetos, de um maker sozinho até uma equipe média.
A sua prioridade não é a analítica exploratória, e sim servir a mesma consulta pré-definida a milhares de usuários simultâneos com latência de milissegundos, alimentada por streaming a partir do Kafka? → Druid ou Pinot. E só se você tiver gente dedicada a operá-los.

O erro que mais vezes vi é pular o passo 1 por instinto —"vamos montar algo sério"— quando 80% do volume real cabia em uma máquina. E o segundo erro, menos frequente mas mais caro, é chegar ao passo 3 sem ter a carga que o justifica: você acaba operando um cluster de seis processos para um problema que o ClickHouse resolvia com um binário.

A tabela comparativa

	DuckDB	ClickHouse	Apache Druid	Apache Pinot
Arquitetura	Embutida, in-process, sem servidor	Colunar distribuída, um binário por nó	Colunar distribuída, processos especializados	Colunar distribuída, processos especializados
Implantação mínima	Uma biblioteca (`pip install duckdb`)	1 binário	6 tipos de processo + ZooKeeper + metadata store	Controller, Broker, Server + ZooKeeper
Melhor caso de uso	Análise local, notebooks, ETL, backend de um app que consulta os próprios arquivos Parquet/CSV	Tabela de eventos em produção com agregações frequentes, self-hosted	Ingestão streaming com exploração ad-hoc e tiering de dados quentes/frios	Servir a mesma consulta pré-definida a concorrência massiva com SLA de milissegundos
Complexidade operacional	Nula: não há nada para operar	Baixa–média: mais um serviço para manter	Alta: exige equipe dedicada	Alta: exige equipe dedicada
Ingestão streaming	Não se aplica	Boa (Kafka engine, views materializadas)	Excelente, sua razão de existir	Excelente, sua razão de existir
Concorrência	Baixa (um processo)	Muito boa	Boa	Excelente, desenhada para isso
Consultas ad-hoc flexíveis	Excelente	Excelente	Boa	Limitada: brilha com padrões conhecidos de antemão
Quando NÃO usar	Você precisa que vários leitores/escritores compartilhem os dados ao vivo, ou escalar além de uma máquina	Você precisa de latência sub-segundo garantida a dezenas de milhares de QPS concorrentes	Você é uma equipe pequena sem SREs dedicados, ou a prioridade é exploração livre sem padrões fixos	Você é uma equipe pequena sem SREs dedicados, ou as suas consultas mudam de forma o tempo todo

As células são simplificações; o detalhe está nas seções seguintes.

DuckDB: quando você não precisa de um serviço

O DuckDB foi criado por Mark Raasveldt e Hannes Mühleisen no CWI (Centrum Wiskunde & Informatica) de Amsterdã, com a primeira versão pública anunciada em 2019 na conferência SIGMOD. A motivação de origem é reveladora: eles vinham tentando embutir o MonetDB em pacotes de R e Python, e descobriram que nenhum banco de dados analítico existente estava desenhado para viver dentro de outro processo sem assumir que ele mandava. O DuckDB nasceu para preencher exatamente esse buraco.

É, na prática, o que o SQLite é para OLTP, mas para analítica: uma biblioteca, não um serviço. pip install duckdb e você já tem um motor colunar vetorizado rodando dentro do seu script, com dialeto SQL compatível com PostgreSQL. Consulta Parquet e CSV direto do disco ou de uma URL, integra de forma nativa com pandas e Polars, e não há porta para abrir nem processo para supervisionar.

Onde ganha: qualquer fluxo em que uma só pessoa ou um só processo faz as consultas. Ciência de dados exploratória, notebooks, o backend analítico de um app pequeno que só precisa ler os próprios dados, pipelines de ETL que transformam arquivos. Para esse perfil de carga, é difícil encontrar um rival sério em simplicidade.

Onde perde, e por que isso não é um defeito e sim um desenho: o DuckDB é fundamentalmente um único processo. Não serve dados a dezenas de leitores concorrentes a partir de máquinas distintas, não escala horizontalmente, e não foi pensado para receber escritas constantes de várias fontes ao mesmo tempo. Existe o MotherDuck como camada cloud para quem precisa compartilhá-lo, mas nesse momento você já mudou de categoria de ferramenta.

O sinal de que já não serve: quando você precisa que vários serviços escrevam ao mesmo tempo e vários clientes leiam ao mesmo tempo, sem que uns bloqueiem os outros. Aí você cruza para o ClickHouse.

ClickHouse: o ponto de equilíbrio para produção

Se o DuckDB resolve "um processo, os meus dados", o ClickHouse resolve "um serviço, os dados de todos". É a opção quando você precisa que a analítica deixe de ser um script que você mesmo executa e vire algo que recebe escritas 24/7 da sua aplicação e responde consultas da sua equipe ou dos seus clientes.

Não vou repetir aqui toda a arquitetura colunar e os índices esparsos —cubro isso com detalhe em o que é ClickHouse e como instalá-lo—, mas o resumo para esta decisão é: um binário, sem JVM, sem ZooKeeper obrigatório, que escala de um notebook até centenas de nós com o mesmo motor.

Onde ganha frente a Druid e Pinot: tudo o que não for o caso extremo de concorrência massiva com SLA de milissegundos. Consultas ad-hoc exploratórias, JOINs razoáveis, uma equipe pequena que não tem SREs dedicados, custo operacional baixo. A imensa maioria de "preciso de tempo real" na verdade significa "preciso que o dado esteja disponível em segundos, não em minutos", e aí o ClickHouse sobra.

Onde perde frente a Druid e Pinot: se o seu SLA real é de milissegundos com dezenas de milhares de consultas concorrentes idênticas —pense em um recurso de produto que centenas de milhares de usuários finais consultam ao mesmo tempo— o ClickHouse pode ficar curto sem um esforço considerável de tuning, enquanto Druid e Pinot estão desenhados desde o zero para exatamente esse perfil.

Quando NÃO usar ClickHouse neste contexto: se os seus dados cabem em uma máquina e quem consulta é um único processo, é excesso de engenharia frente ao DuckDB. Se o seu SLA é de milissegundos a concorrência extrema com streaming a partir do Kafka, é a ferramenta errada frente a Druid ou Pinot.

Druid e Pinot: quando você de fato precisa de tempo real em escala massiva

Druid e Pinot compartilham família: ambos rodam sobre a JVM, ambos separam o sistema em vários tipos de processo especializados, ambos dependem do ZooKeeper para coordenação, e ambos esperam um cano de ingestão tipo Kafka alimentando-os o tempo todo. Ambos também são, de forma notável, mais complexos de operar do que o ClickHouse: não é uma opinião, é uma consequência direta de ter seis (Druid) ou três (Pinot) tipos de processo distintos para implantar, monitorar e escalar em separado, em vez de um binário.

Mas não são intercambiáveis entre si, porque nasceram para resolver problemas distintos.

Apache Druid: da analítica de ad-tech ao streaming geral

O Druid nasceu em 2011 dentro da Metamarkets, uma empresa de publicidade programática que precisava analisar bilhões de eventos com drill-down e roll-up em tempo real e descobriu que nem o MySQL nem o HBase davam a velocidade necessária. Foi aberto como open source em 2012 e passou à licença Apache em 2015.

Essa origem —analítica exploratória sobre streams de eventos, com dimensões que mudam e usuários que querem cortar os dados de formas não previstas— continua marcando o desenho. O Druid separa de forma explícita os dados "quentes" (recentes, em memória) dos "frios" (históricos, em armazenamento profundo), e isso o deixa forte para quem precisa de retenção longa com consultas exploratórias sobre o histórico completo, não só sobre o último.

Onde ganha frente ao Pinot: flexibilidade para consultas ad-hoc não antecipadas e gestão de dados por antiguidade. Se a sua equipe de analistas quer poder perguntar coisas novas sobre o histórico sem redesenhar índices, o Druid dá mais margem.

Apache Pinot: nascido para servir, não para explorar

O Pinot nasceu no LinkedIn com um objetivo bem mais estreito e específico: servir funcionalidades como "quem viu o seu perfil" a centenas de milhões de usuários com latência de milissegundos. Não é coincidência que a arquitetura —índices em estrela, índices invertidos, particionamento pensado para padrões de acesso conhecidos— esteja otimizada para executar a mesma forma de consulta uma e outra vez, muito rápido, para muita gente ao mesmo tempo.

Onde ganha frente ao Druid: concorrência bruta em consultas predefinidas. Se você sabe de antemão a forma das consultas que vai servir —um dashboard de produto com filtros fixos, um contador de métricas por usuário— e a prioridade é aguentar dezenas de milhares de consultas simultâneas com latência mínima, o Pinot está mais afinado para exatamente isso.

Onde perde frente ao Druid: consultas exploratórias com formas novas. O Pinot brilha quando você conhece os seus padrões de acesso e indexa para eles; incomoda quando alguém quer perguntar algo que ninguém antecipou.

A regra prática Druid vs. Pinot

Se o seu problema é "analítica em tempo real de frente para uma equipe interna que explora livremente", incline-se pelo Druid. Se o seu problema é "analítica em tempo real de frente para o usuário final, com consultas previsíveis e concorrência massiva", incline-se pelo Pinot. E se você não tem claro qual dos dois cenários descreve o seu caso, é um sinal bastante forte de que ainda não precisa de nenhum dos dois: provavelmente o seu problema real é o passo 2 da árvore, não o passo 3.

Quando NÃO usar nenhum dos dois: se a sua equipe são poucas pessoas sem experiência operando sistemas distribuídos sobre JVM, o custo de manter seis processos coordenados pelo ZooKeeper não se amortiza salvo em escalas muito grandes. É sintomático que várias empresas conhecidas tenham migrado cargas do Druid para o ClickHouse citando redução de custo e simplicidade, precisamente porque o volume real não exigia a complexidade que estavam pagando.

Casos reais mapeados

Para descer isso da teoria, quatro cenários concretos e para qual ferramenta apontam:

Analista de dados explorando vendas históricas em Parquet a partir de um notebook. DuckDB. Sem discussão: um processo, dados que cabem no notebook, zero necessidade de compartilhar estado com ninguém.

SaaS B2B com uma tabela de eventos de produto que cresce todo dia e um dashboard interno que várias pessoas consultam. ClickHouse. Serviço compartilhado, escritas contínuas, concorrência moderada, sem necessidade de latência de milissegundos garantida.

Plataforma de ad-tech que ingere impressões a partir do Kafka e precisa que a equipe de analistas corte esses dados por dimensões arbitrárias em tempo quase real, com retenção de meses. Druid. Ingestão streaming, exploração flexível, tiering quente/frio.

Rede social ou produto de consumo massivo que mostra uma métrica personalizada —"as suas estatísticas desta semana"— a milhões de usuários simultâneos com um SLA de latência estrito. Pinot. Consulta predefinida, concorrência extrema, padrão de acesso conhecido de antemão.

Se o seu cenário não encaixa com clareza em nenhum dos quatro, volte à árvore de decisão do começo: quase sempre a resposta correta é a opção mais simples que resolve o problema de hoje, não a mais impressionante.

Perguntas frequentes

DuckDB ou ClickHouse?

DuckDB se um único processo faz as consultas e os seus dados cabem em uma máquina: notebooks, ETL, backend de um app pequeno. ClickHouse quando você precisa de um serviço compartilhado com escritas contínuas de várias fontes e vários leitores concorrentes. A fronteira é "biblioteca" vs. "serviço", não desempenho.

ClickHouse ou Druid, qual escolher?

ClickHouse para a imensa maioria dos casos: menor complexidade operacional, um binário frente a seis tipos de processo, e desempenho de sobra para analítica de propósito geral. Druid só se a sua carga real é ingestão streaming massiva com exploração ad-hoc sobre dados quentes e frios, e você tem equipe dedicada a operá-lo.

Apache Pinot vs. Druid vs. ClickHouse, qual é melhor?

Não há um "melhor" universal. ClickHouse para analítica geral em produção com complexidade operacional baixa. Druid para streaming com exploração flexível e gestão de dados por antiguidade. Pinot para servir consultas predefinidas a concorrência massiva com latência de milissegundos. Escolha pelo seu padrão de carga, não pelo benchmark.

ClickHouse ou Vertica?

São categorias distintas mais do que parece. Vertica é um MPP colunar proprietário (com uma edição community limitada) pensado para grandes empresas com orçamento de licença e equipe de DBA. O ClickHouse é open source sem custo de licença, implanta-se como um binário e encaixa muito melhor com uma equipe pequena que quer self-hosting sem negociar um contrato.

Posso migrar de Druid ou Pinot para ClickHouse mais adiante, ou o contrário?

Sim, nas duas direções, embora não seja trivial: os modelos de ingestão e as consultas mais idiomáticas de cada um não são uma cópia direta. O habitual é começar pelo ClickHouse pelo menor custo operacional e migrar para Druid ou Pinot só se a concorrência ou o SLA real exigirem de forma mensurável, não antecipada.

Conclusão

As quatro ferramentas deste post são excelentes no que fazem, e essa é precisamente a razão de a pergunta "qual é melhor?" estar mal formulada. O DuckDB ganha quando o trabalho é feito por um processo. O ClickHouse ganha quando você precisa de um serviço de propósito geral com complexidade operacional razoável. Druid e Pinot ganham só no extremo de streaming massivo com SLA de milissegundos, e só se você tiver quem os opere.

Para a maioria dos projetos que começam hoje, o caminho natural é começar pelo DuckDB enquanto os dados cabem em uma máquina, e dar o salto para o ClickHouse quando precisar que essa análise vire um serviço compartilhado. Se você chegar de verdade ao degrau do Druid ou do Pinot, vai saber porque a dor será concreta e mensurável, não uma intuição de que "isso tem que ser maior do que é".

Se o ClickHouse é o seu próximo passo, o caminho mais curto é o que é ClickHouse e como instalá-lo, e se quiser ver o resto das opções do mercado com mais detalhe, a comparativa de alternativas ao ClickHouse entra em StarRocks, TimescaleDB e os warehouses cloud que este post deixa de fora de propósito por não encaixarem na árvore de decisão de motores em tempo real.