Índice

• Como avaliar um banco de dados analítico (os critérios que importam)
• A tabela comparativa
• Análise opção por opção

  • DuckDB — o rival que mais gente deveria considerar primeiro
  • StarRocks — a alternativa séria se os teus dados estão normalizados
  • Apache Druid — potente e operacionalmente caro
  • Apache Pinot — o rei da analítica voltada ao utilizador
  • TimescaleDB (TigerData) — a alternativa que não te obriga a migrar
  • BigQuery e Snowflake — zero operações, fatura variável
  • Menção à parte: Apache Doris e Tinybird
• Veredicto: o que escolher segundo a tua situação
• O que aprendi a escolher mal
• Conclusão
• Perguntas frequentes

  • Qual é a melhor alternativa a ClickHouse?
  • ClickHouse ou DuckDB?
  • ClickHouse ou BigQuery?
  • StarRocks é melhor que ClickHouse?
  • Apache Druid ainda vale a pena em 2026?

Como avaliar um banco de dados analítico (os critérios que importam)

Antes da tabela, convém fixar os eixos. Vi gente demais a escolher por benchmark e a arrepender-se por operações.

Custo operacional real. Não o preço de licença —quase todas são open source— mas quantas horas por mês vai dedicar a mantê-la viva. Este é o critério que mais pesa quando se trabalha só e o que menos aparece nas comparativas.

Modelo de implantação. Um binário? Um cluster de seis tipos de processo? Só cloud gerenciado? Determina se pode começar num VPS de 20 € ou precisa de Kubernetes.

Latência de ingestão. Quanto tarda um evento em ser consultável? Segundos, minutos ou horas. Só importa se precisar mesmo de tempo real; muita gente acha que precisa e não precisa.

Concorrência. Quantas consultas simultâneas aguenta? Crítico se constrói analítica dentro do seu produto para os seus clientes; irrelevante se é um dashboard interno que três pessoas olham.

Modelo de custos em escala. Pagamento por consumo (BigQuery, Snowflake) vs. servidor fixo (ClickHouse self-hosted). O primeiro é genial quando o uso é baixo e aterrorizante quando alguém deixa um dashboard auto-atualizando.

Ecossistema e maturidade de drivers. Se o seu stack é Python ou Node, há cliente oficial? Conecta-se a Metabase ou Grafana sem sofrer?

A tabela comparativa

Leia-a sabendo que as células são simplificações e que o detalhe está nas seções seguintes.

	ClickHouse	DuckDB	StarRocks	Apache Druid	Apache Pinot	TimescaleDB	BigQuery / Snowflake
Tipo	OLAP colunar distribuída	OLAP embutida (in-process)	OLAP colunar MPP	OLAP tempo real	OLAP tempo real	Extensão de PostgreSQL	Warehouse cloud gerenciado
Licença	Apache 2.0	MIT	Apache 2.0	Apache 2.0	Apache 2.0	Apache 2.0 / TSL	Proprietária
Implantação mínima	1 binário	1 biblioteca	Frontend + Backend nodes	6 tipos de processo + ZooKeeper	Controller, Broker, Server + ZooKeeper	Postgres + extensão	Só SaaS
Dificuldade operativa	Baixa—média	Nula	Média	Alta	Alta	Muito baixa	Nula (pagas por isso)
Desempenho consultas agregadas	Excelente	Excelente (single-node)	Excelente	Muito bom	Muito bom	Bom	Bom—muito bom
JOINs complexos	Muito bom	Excelente	Excelente (sua força)	Limitado	Limitado (a melhorar)	Excelente (é Postgres)	Excelente
Ingestão streaming	Boa (Kafka engine, MVs)	Não aplica	Boa	Excelente	Excelente (sua força)	Boa	Média (batch-first)
Latência ingestão—consulta	Segundos	N/A	Segundos	Sub-segundo	Sub-segundo	Imediata	Minutos
Concorrência alta	Muito boa	Baixa (um processo)	Muito boa	Boa	Excelente	Média	Boa mas cara
UPDATE / DELETE	Limitado (mutações leves)	Sim	Sim (sua força)	Muito limitado	Muito limitado	Completo	Sim (custoso)
Dialeto SQL	Próprio, muito estendido	Compatível Postgres	Compatível MySQL	SQL próprio	SQL próprio	PostgreSQL puro	SQL padrão
Escala prática	TB—PB	GB—centenas de GB	TB—PB	TB—PB	TB—PB	GB—dezenas de TB	PB
Modelo de custo	Servidor fixo	Grátis (corre no seu processo)	Servidor fixo	Servidor fixo (caro)	Servidor fixo (caro)	Servidor fixo	Por consumo
Encaixe para um maker só	✅ Sim	✅ Sim	⚠️ Com esforço	❌ Não	❌ Não	✅ Sim	⚠️ Risco de fatura

Análise opção por opção

DuckDB — o rival que mais gente deveria considerar primeiro

DuckDB é um banco de dados analítico in-process: não há servidor, corre dentro da sua aplicação como uma biblioteca, igual a SQLite mas para analítica. pip install duckdb e já tens um motor colunar vetorizado.

Onde ganha claramente: simplicidade absoluta. Zero operações, zero portos, zero backups para configurar. Consulta Parquet e CSV diretamente, integra-se com pandas e Polars de forma nativa, e o seu dialeto SQL é compatível com PostgreSQL, por isso não aprendes uma sintaxe nova. Para análise de dados locais, notebooks, ETL, ou o backend analítico de uma app pequena, é difícil de superar.

Onde perde: é fundamentalmente um único processo. Não serve dados a dezenas de utilizadores concorrentes, não escala horizontalmente, e não está pensada para ser um serviço partilhado que recebe escritas constantes desde várias fontes. Existe MotherDuck como camada cloud se precisas disso, mas então já estás noutro modelo.

A minha opinião: se o teu dataset cabe num disco e as tuas consultas são lançadas pelo teu backend ou por ti desde um notebook, começa por DuckDB, não por ClickHouse. É a recomendação que mais gente resiste e a que mais vezes resulta correta. A complexidade adiciona-se quando dói não a ter.

A fronteira prática está onde precisas um serviço em vez de uma biblioteca: múltiplos escritores, múltiplos leitores concorrentes, dados que não cabem comodamente numa máquina, retenção de anos. Aí cruzas para ClickHouse.

StarRocks — a alternativa séria se os teus dados estão normalizados

StarRocks é um banco de dados MPP colunar que partilha muita filosofia com ClickHouse mas diferencia-se em dois pontos que importam.

Onde ganha: JOINs multi-tabela e atualizações em tempo real. StarRocks foi desenhada desde o início assumindo que consultarias um esquema em estrela normalizado, com um otimizador de custos maduro para reordenar joins. Se vens de um data warehouse tradicional com tabelas de factos e dimensões e não queres desnormalizar tudo, encaixa melhor. Também é compatível com o protocolo MySQL, o que significa que qualquer cliente MySQL se conecta sem driver especial.

Onde perde: ecossistema e comunidade mais pequenos que ClickHouse. Menos integrações prontas, menos respostas no Stack Overflow quando algo se parte às 2 da madrugada, menos engenheiros que já a conheçam. E a instalação mínima envolve dois tipos de nó (frontend e backend), não um binário.

A minha opinião: é a alternativa tecnicamente mais equiparável a ClickHouse. Se a tua carga de trabalho é "warehouse com muitos joins e updates frequentes", avalia-a a sério. Se a tua carga é "torrente de eventos que agrego por tempo", ClickHouse segue sendo mais simples e mais rápido de pôr em marcha.

Apache Druid — potente e operacionalmente caro

Druid leva anos fazendo analítica de séries temporais em tempo real em grande escala, e fá-lo bem. A sua arquitetura está muito afinada para ingestão desde Kafka com disponibilidade imediata dos dados.

Onde ganha: ingestão em streaming com latência sub-segundo e separação clara entre dados "quentes" (recentes, em memória) e "frios" (históricos, em armazenamento profundo). Para um caso de uso de monitorização em grande escala com retenção longa, o design faz sentido.

Onde perde: a complexidade operativa. Druid precisa de Coordinator, Overlord, Broker, Router, Historical e MiddleManager, mais ZooKeeper para coordenação e um metadata store. Isso são seis tipos de processo mais duas dependências externas. É um cluster que requer gente dedicada. Além disso os JOINs seguem sendo o seu ponto fraco, e o modelo de dados é menos flexível.

A minha opinião: para um maker ou uma equipa pequena, Druid é diretamente inviável. Não porque seja má tecnologia —não o é— mas porque o seu custo de operação não se amortiza salvo em escalas muito grandes. É sintomático que várias empresas conhecidas (Lyft entre elas) tenham migrado de Druid para ClickHouse citando redução de custo e simplificação de arquitetura.

Apache Pinot — o rei da analítica voltada ao utilizador

Pinot nasceu no LinkedIn para servir "quem viu o teu perfil" a centenas de milhões de utilizadores. Esse DNA nota-se: está otimizado para latências de milissegundos com concorrência muito alta.

Onde ganha: se constróis uma funcionalidade analítica dentro do teu produto que milhares de utilizadores consultarão simultaneamente com um SLA de latência estrito, Pinot tem a arquitetura mais especificamente desenhada para isso. Índices em estrela, índices invertidos, particionamento afinado para esse padrão.

Onde perde: igual a Druid, complexidade operativa alta (Controller, Broker, Server, mais ZooKeeper). Menos flexível para consultas ad-hoc exploratórias: brilha quando conheces os teus padrões de consulta de antemão e podes indexar para eles, não quando queres explorar.

A minha opinião: ferramenta excelente para um problema muito concreto que quase nenhum projeto pequeno tem. Se não estás a servir analítica a mais de mil utilizadores concorrentes, ClickHouse dá-te 90% do resultado com 20% da complexidade.

TimescaleDB (TigerData) — a alternativa que não te obriga a migrar

TimescaleDB é uma extensão de PostgreSQL para séries temporais. Em junho de 2025 a empresa renomeou-se para TigerData, embora a extensão open source mantenha o nome TimescaleDB.

Onde ganha: é PostgreSQL. Todo o teu conhecimento, os teus drivers, as tuas ferramentas, os teus backups, o teu ORM, os teus JOINs com as tabelas de aplicação: tudo segue a funcionar. Adiciona "hypertables" (particionamento automático por tempo), agregados contínuos e compressão colunar. E como é Postgres, tens transações ACID completas e UPDATE/DELETE sem drama.

Onde perde: o desempenho em agregações sobre volumes muito grandes não está ao nível de ClickHouse. Segue sendo Postgres por baixo, com as limitações de um motor orientado a linhas remendado com compressão colunar. Em dezenas de terabytes, a diferença nota-se muito.

A minha opinião: subvalorizada pela gente que persegue o novo. Se já usas Postgres, os teus dados são séries temporais, e o teu problema é de dezenas ou centenas de gigabytes em vez de terabytes, TimescaleDB é provavelmente a melhor decisão custo-benefício que podes tomar. Migras com uma extensão em vez de com um serviço novo. A complexidade que não adicionas é complexidade que não manténs.

BigQuery e Snowflake — zero operações, fatura variável

Os warehouses cloud gerenciados eliminam por completo o problema operacional. Não há servidor, não há atualizações, não há backups. Escreves SQL e pagas.

Onde ganham: escala praticamente ilimitada sem pensar em infraestrutura, integração profunda com o resto do ecossistema cloud, e maturidade enorme em governação de dados, permissões e compliance. Se és uma empresa com orçamento e queres que a equipa se dedique ao negócio, é uma decisão defensável.

Onde perdem: o modelo de preços. Pagas por dados escaneados (BigQuery) ou por tempo de computação (Snowflake), e ambos os modelos castigam exatamente o padrão da analítica interativa: muitas consultas pequenas e frequentes. Um dashboard com auto-refresh a cada 30 segundos pode gerar uma fatura desproporcional. Além disso a latência de consulta raramente baixa de centenas de milissegundos a segundos, o que os torna pouco adequados para analítica embutida em produto.

A minha opinião: para um projeto bootstrapped, o risco de fatura variável é um risco de negócio, não técnico. Vi projetos onde o custo de BigQuery superou o de toda a resto da infraestrutura junta. Um servidor dedicado com ClickHouse tem um custo conhecido e plano, e isso vale muito quando facturas pouco. A exceção razoável: se os teus dados já vivem em Google Cloud e o teu volume de consultas é baixo e esporádico, BigQuery pode sair mais barato do que manter um servidor.

Menção à parte: Apache Doris e Tinybird

Apache Doris é muito similar a StarRocks (partilham origem) e merece um olhar pelos mesmos motivos. Tinybird é uma camada gerenciada construída sobre ClickHouse que adiciona APIs sobre as tuas consultas — interessante se queres ClickHouse sem o operar e com uma camada de produto por cima.

Veredicto: o que escolher segundo a tua situação

Traduzo tudo o anterior em recomendações concretas.

Estás a explorar dados num notebook ou tens menos de 50 GB — DuckDB. Sem discussão. Zero operações, desempenho excelente, SQL familiar.

Já usas PostgreSQL, os teus dados são temporais, e falamos de dezenas de GB — TimescaleDB. Acrescentas uma extensão em vez de um serviço. A opção mais aborrecida e provavelmente a correta.

Tens um torrente de eventos, queres self-hosting, e trabalhas só ou em equipa pequena — ClickHouse. O ponto ótimo entre desempenho e complexidade operativa. Um binário num VPS aguenta mais do que a maioria dos projetos precisará alguma vez.

Constróis analítica dentro do teu produto para milhares de utilizadores concorrentes — ClickHouse primeiro, Pinot se te ficas curto. Começa pelo simples; migra se o SLA o exigir de verdade.

O teu esquema é um warehouse normalizado com muitos JOINs e updates — StarRocks. O seu otimizador de joins é a sua vantagem real sobre ClickHouse.

Tens orçamento, equipa, e queres zero infraestrutura — BigQuery ou Snowflake. Põe alertas de custo desde o dia um.

Precisas de ingestão sub-segundo em escala massiva e tens SRE dedicados — Druid ou Pinot. Se não tens SRE dedicados, esta linha não é para ti.

O que aprendi a escolher mal

Duas vezes escolhi a ferramenta mais potente em vez da adequada, e nas duas vezes o paguei.

A primeira montei um cluster para um projeto que tinha 12 milhões de linhas. Doze milhões. DuckDB teria respondido essas consultas em milissegundos desde um único ficheiro. Passei um fim de semana a configurar algo que resolvia um problema que não tinha.

A segunda escolhi por benchmark. Os benchmarks de bancos de dados medem latência de consulta em condições de laboratório; não medem quantas horas vais passar a depurar a ingestão, nem o quanto dói que a comunidade seja tão pequena que o teu erro não apareça em lado nenhum. O custo real de um banco de dados é o tempo que te rouba, não os milissegundos que te poupa.

O meu critério atual, por ordem: primeiro escolhe a opção mais simples que resolva o teu problema hoje; segundo, verifica que tem um caminho de saída claro (podes exportar para Parquet?); terceiro, e só então, olha o desempenho. Se a opção mais simples não aguentar dentro de um ano, já migrarás — e para então saberás muito melhor o que precisas.

Conclusão

Não há uma "melhor banco de dados OLAP". Há uma melhor para o teu volume, a tua equipa e o teu orçamento, e para a maioria dos projetos pequenos essa resposta é DuckDB ou ClickHouse, não as opções mais sofisticadas.

ClickHouse ocupa um espaço muito particular neste panorama: desempenho de sistema distribuído com complexidade operativa de aplicação monolítica. Essa combinação é rara e é a razão pela que segue sendo a minha opção por defeito quando o projeto superou o que DuckDB pode dar.

Se já te decidiste por ClickHouse, o próximo passo é tirar-lhe partido de verdade: o guia avançado de ClickHouse cobre vistas materializadas, projections, codecs e tudo o que separa um ClickHouse medíocre de um rápido. E se ainda não o tens instalado, começa por o que é ClickHouse e como instalá-lo.

---

Perguntas frequentes

Qual é a melhor alternativa a ClickHouse?

Depende do caso. DuckDB para datasets que cabem numa máquina, StarRocks se precisas de JOINs complexos e atualizações frequentes, TimescaleDB se já usas PostgreSQL, e Apache Pinot se a tua prioridade é latência mínima com concorrência muito alta.

ClickHouse ou DuckDB?

DuckDB se os teus dados cabem num disco e as consultas são lançadas por um único processo. ClickHouse quando precisas de um serviço partilhado, escritas concorrentes desde várias fontes ou escalar para além de uma máquina.

ClickHouse ou BigQuery?

ClickHouse se queres custo plano e previsível e latências de milissegundos; BigQuery se preferes zero operações, o teu volume de consultas é baixo e esporádico, e os teus dados já vivem em Google Cloud.

StarRocks é melhor que ClickHouse?

Em JOINs multi-tabela e atualizações em tempo real, geralmente sim. Em simplicidade de implantação, tamanho de comunidade e ecossistema de integrações, ClickHouse mantém vantagem.

Apache Druid ainda vale a pena em 2026?

Em escalas muito grandes com equipas de infraestrutura dedicadas, sim. Para projetos pequenos e médios, o seu custo operativo raramente se justifica face a ClickHouse.