ClickHouse benchmark 2026: análisis de ClickBench y comparación en LATAM

Resumen en un minuto

Un equipo de ingeniería en Lima, Santiago o Bogotá compara ClickHouse contra lo que ya tiene — normalmente PostgreSQL haciendo analítica, o Snowflake con factura de USD 8–15k al mes. La reacción siempre es la misma: «no puede ser». Queries 100 veces más rápidas, compresión 10–30x, USD 80 por terabyte-mes de almacenamiento en lugar de USD 23 más compute. Los números suenan a marketing.

No lo son. Son verificables. El benchmark abierto ClickBench compara más de 60 motores con 43 queries en el mismo hardware, y los resultados se reproducen en un portátil en media tarde. Este artículo analiza qué dicen esos números para un equipo que decide entre migrar a ClickHouse, quedarse con Snowflake, o armar un híbrido. Sin hype, con los límites bien marcados.

• ClickBench es el único benchmark público con metodología reproducible para más de 60 motores OLAP. Dataset: ~100 millones de filas de analítica web (~14 GB Parquet), 43 queries, cold + 2 hot runs en AWS c6a.4xlarge (16 vCPU, 32 GB RAM, gp2 SSD).
• ClickHouse cae en el top-3 en la mayoría de queries. Los rivales serios en hot-query latency son Umbra (prototipo académico), StarRocks y Databend. DuckDB lidera en cold-runs cortos hasta 10 GB.
• Compresión 10–30x contra Parquet crudo — resultado típico en datos OLAP con repeticiones y orden.
• Brecha de costo vs Snowflake: para workload equivalente, ClickHouse self-hosted sale 3–10x más barato, ClickHouse Cloud sale 2–5x más barato en cargas OLAP típicas.
• NO funciona en: cargas transaccionales con UPDATE/DELETE frecuentes, joins entre tablas de más de 1.000 millones de filas, datasets pequeños (<10M filas — DuckDB resulta más cómodo).
• PYME en LATAM: ClickHouse se justifica cuando las queries analíticas en PostgreSQL empiezan a tardar más de 5 segundos o la tabla supera los 100 GB.

Qué es ClickBench y por qué se le puede creer

ClickBench lo lanzó el equipo de ClickHouse en 2022 y lo mantiene la comunidad open-source. Todos los scripts, el dataset y las specs de hardware están publicados en GitHub — cualquier equipo reproduce los resultados en su propia infraestructura. El vendor de un motor puede enviar un pull request actualizando sus resultados, pero la metodología está fija: no se puede «optimizar para el benchmark» con hacks específicos.

Qué mide:

• Dataset «hits»: 99.997.497 filas de analítica web del dump público de Yandex.Metrica. Tamaño en Parquet crudo — ~14 GB. Es carga OLAP con cardinality típica (URL, UserAgent, OS, Region), repeticiones y columnas temporales.
• 43 queries de distinta complejidad: COUNT con filtros, GROUP BY sobre columnas de alta cardinality, top-N con ORDER BY + LIMIT, regex match, agregaciones time-series con DATE_TRUNC, JOIN contra dimension tables chicas.
• Cada query corre 3 veces: primer run cold (cache vacío), luego 2 hot runs (cache calentado).
• Hardware fijo: c6a.4xlarge para motores self-hosted. Servicios cloud se prueban en compute equivalente.
• Métricas reportadas: tiempo de carga, tamaño en disco, tiempo mínimo de cada uno de los 3 runs.

Qué NO mide (importante para entender los límites):

• Carga transaccional (OLTP), workloads pesados en UPDATE/DELETE.
• Joins entre tablas de más de 100M filas (solo lookup-joins contra dimension tables).
• Concurrencia multi-usuario (queries simultáneas de 50+ analistas).
• Streaming ingestion en tiempo real con throughput custom.

Es decir: ClickBench responde a «qué motor es más rápido en una carga OLAP típica de un solo usuario», pero no a «cuál aguanta 500 analistas concurrentes con 50% de UPDATEs». Si querés evaluar eso último — necesitás tus propias queries sobre tus propios datos.

Resultados actuales: quién gana y por cuánto

En hardware single-node (c6a.4xlarge) el liderazgo se reparte de manera estable entre varios motores. Los números exactos se actualizan en benchmark.clickhouse.com, abajo están los patrones que se mantienen en los últimos 12 meses.

Tiempo de carga de 100M filas (Parquet → motor): DuckDB tarda decenas de segundos (zero-copy con read_parquet). ClickHouse necesita unos minutos con conversión a MergeTree (LZ4 default). Snowflake y BigQuery — unos minutos en un warehouse mediano. Druid y Pinot — decenas de minutos (requieren indexación en el ingestion).

Compresión real: ClickHouse con LZ4 produce ~4–5 GB para el dataset hits (3x compresión vs Parquet, 30x vs CSV crudo). Con ZSTD baja a 2–3 GB (5x vs Parquet, 50x vs CSV). Druid y Pinot ocupan más por sus inverted indices. Snowflake usa micropartitions de 3–4 GB.

Conclusión principal: la diferencia entre los motores top es menor que la diferencia entre cualquier motor OLAP top y PostgreSQL/MySQL. Estos últimos son 100–1000 veces más lentos en una carga OLAP típica.

Cuándo ClickHouse da el ROI máximo en LATAM

Entre «ClickHouse es más rápido en el benchmark» y «ClickHouse nos sirve» hay distancia. Cuatro situaciones donde el benchmark se traduce en business case real.

#1. La analítica sobre PostgreSQL ya tarda demasiado

Retail en Chile o Perú con 50–200 GB de datos transaccionales. Dashboards de Metabase o Power BI tardan 15–30 segundos en cargar. PostgreSQL es row-oriented y no está optimizado para OLAP. Replicás los datos a ClickHouse vía el engine de PostgreSQL o por CDC (Debezium → Kafka → ClickHouse), y las mismas queries corren en 0.1–1 segundo. Storage columnar más vectorized execution en acción.

#2. La factura de Snowflake superó los USD 5k/mes

Un warehouse X-Small encendido 4 horas al día son USD 1.300+ mensuales. Un equipo activo de 10 analistas llega tranquilo a USD 8–15k/mes. ClickHouse self-hosted en compute equivalente (3 nodos c6a.4xlarge en AWS São Paulo) sale USD 1.100–1.500/mes más ~4–8 horas de DevOps por semana. ClickHouse Cloud en la misma región — USD 3–5k/mes para workload equivalente sin DevOps a cargo del equipo.

#3. Real-time analytics dentro del producto

E-commerce en Colombia, marketplace en Ciudad de México. Hay que mostrarle al usuario estadística en vivo: ventas del día, top de categorías, estado de pedidos. El budget de latencia es de 100 milisegundos. PostgreSQL no llega. BigQuery tampoco, por su overhead de planning de 1–2 segundos. ClickHouse sí llega. Cloudflare usa ClickHouse exactamente para esto: analítica HTTP en tiempo real a escala de trillions de eventos.

#4. Observability y logs

SaaS en Argentina con 100+ microservicios y 50 TB de logs al mes. Elasticsearch sale USD 30–50k/mes y vive con problemas de shard balancing. ClickHouse + Vector (o Fluent Bit) sale USD 5–10k/mes, es notablemente más rápido en agregaciones y solo pierde en full-text search. Patrón documentado en el artículo sobre arquitectura de datos en tiempo real.

Cuándo ClickHouse no es la respuesta

Tres escenarios donde forzar ClickHouse termina mal.

#1. Cargas transaccionales con UPDATE/DELETE

ClickHouse no es OLTP. Si necesitás updates con consistencia inmediata (estado del pedido en el checkout) — no uses ClickHouse como primary storage. ReplacingMergeTree y los comandos UPDATE existen, pero son eventually consistent y aguantan mal updates de alta frecuencia. Patrón correcto: PostgreSQL para OLTP, ClickHouse para la copia OLAP vía CDC.

#2. Joins entre tablas de más de 1.000 millones de filas

ClickHouse está optimizado para star schema con dimension tables chicas. Joins pesados (fact-fact en miles de millones de filas) — ClickHouse es más lento que Snowflake o BigQuery con su arquitectura MPP. Alternativas: pre-agregación con materialized views, o ETL hacia una tabla denormalizada con el JOIN ya materializado.

#3. Dataset chico (<10M filas), analítica ad-hoc

Una PYME con 10 GB de datos — ClickHouse es excesivo. DuckDB + Parquet resuelve el problema más simple, sin servidor. PostgreSQL con materialized views también alcanza. ClickHouse se justifica desde el momento en que los datos superan 50–100 GB o las queries empiezan a tardar más de 2 segundos.

Errores típicos al hacer benchmark

#1. Correr ClickBench «as is» y decidir con eso

ClickBench mide performance single-node en una carga típica de analítica web. Si tu negocio es e-commerce, fintech, IoT u observability — necesitás tus propias queries sobre tus propios datos. Tomá las 10–20 queries más frecuentes de producción, corrélas en ClickHouse vs el stack actual, compará mediana y p95 de latencia.

#2. Comparar on-prem ClickHouse contra Snowflake X-Small

Snowflake X-Small son 8 cores. ClickHouse en c6a.4xlarge son 16 cores. La comparación tiene que ser por compute equivalente. Un benchmark real fija la métrica clave como (USD/hora de hardware) × (queries por hora) = USD/query.

#3. Ignorar la latencia de ingestion

Si vas a meter 100k events/sec — verificá que ClickHouse aguante con tu schema (PRIMARY KEY, TTL, PARTITION BY). Error típico: PARTITION BY demasiado granular (por hora, por ejemplo) → millones de parts → degradación de performance en las queries.

#4. Bench de ClickHouse comprimido vs Snowflake sin comprimir

El default de ClickHouse es LZ4. Snowflake también comprime. El tamaño en disco hay que compararlo en condiciones iguales. Mejor — comparar el costo USD/TB-mes de storage: ClickHouse self-hosted en AWS gp3 sale ~USD 80/TB/mes, Snowflake ~USD 23/TB/mes (en Snowflake el storage es la parte chica de la factura, lo que domina es compute).

#5. Bench sin distribución de datos de producción

El dataset de ClickBench tiene una cardinality específica. Los datos reales suelen tener skew (90% de las queries cae sobre el 5% de los datos). Para un benchmark honesto — sampleá data de producción, no sintética.

Caso anónimo: de Snowflake a ClickHouse Cloud

Marketplace de e-commerce con base en Bogotá (caso anonimizado). Punto de partida: 6 TB de datos históricos en Snowflake, 20–30 analistas, factura subiendo hasta USD 18k/mes. La mayor parte de la factura — refreshes de dashboards para el equipo de producto cada 5 minutos.

«El refresh de los dashboards dominaba la factura. Cuando vimos que el costo unitario por query había crecido 6x en un año, dejó de tener sentido escalar el warehouse.»

Qué hicieron:

1. Midieron las top-50 queries más caras de Snowflake con la view QUERY_HISTORY.
2. Las reprodujeron en ClickHouse Cloud (tier production, AWS São Paulo) con datos reales. La latencia mediana de las queries analíticas cayó de 4–8 segundos a 0.3–1 segundo.
3. Plan de migración: dbt models traducidos en 3 semanas (el dialecto SQL de ClickHouse es cercano a PostgreSQL; las diferencias principales son la falta de MERGE y particularidades de window functions).
4. Streaming-ingestion vía Kafka Engine de ClickHouse (en lugar de Snowpipe).
5. Dashboards conmutados a ClickHouse. Snowflake quedó solo para almacenamiento histórico de largo plazo (parked).

Resultado a los 3 meses:

• Factura bajó de USD 18k a USD 4.5k/mes en ClickHouse Cloud más USD 300 de storage en Snowflake.
• Refresh de dashboards — 0.5–2 segundos en lugar de 5–15.
• El equipo de producto empezó a lanzar 4x más queries ad-hoc (la latencia dejó de ser barrera psicológica).

Límites del caso: la migración insumió ~12 semanas-ingeniero (data engineer + analytics engineer). Modelos dbt con joins pesados hubo que reescribirlos. Algunas queries con window functions avanzadas requirieron optimización — ClickHouse no soporta todas las extensiones específicas de Snowflake.

Descarga el template de benchmark para equipos LATAM

Preparé un «ClickHouse vs tu stack actual: benchmark template». Adentro:

• Docker-compose con ClickHouse, DuckDB y PostgreSQL para comparación lado a lado.
• 20 queries OLAP típicas sobre datos anonimizados de e-commerce, fintech y observability.
• Calculadora Excel de USD/query para self-hosted vs Cloud vs Snowflake/BigQuery con pricing de AWS São Paulo.
• Checklist de migración si decidís moverte desde Snowflake, BigQuery o PostgreSQL.

Dejá el email en la sección de recursos y te lo mando en 5 minutos.

Preguntas frecuentes