ClickHouse para desarrolladores que vienen de PostgreSQL

ClickHouse es una base de datos columnar diseñada para análisis de grandes volúmenes de datos. Si vienes de PostgreSQL, muchas cosas te van a resultar familiares porque ClickHouse habla SQL. Pero las diferencias internas son enormes y si las ignoras vas a sufrir. Este post explica ClickHouse desde la perspectiva de alguien que ya sabe PostgreSQL.

Qué problema resuelve

PostgreSQL es una base de datos de propósito general optimizada para transacciones: inserta una fila, lee una fila, actualiza una fila. Es excelente para la operativa diaria de una aplicación.

ClickHouse resuelve un problema diferente: consultas analíticas sobre millones o miles de millones de filas. "¿Cuántas llamadas se hicieron ayer agrupadas por país y hora?" "¿Cuál es la tendencia de facturación de los últimos 36 meses?" "¿Qué páginas generan más tráfico los martes entre las 10 y las 14?"

En PostgreSQL, estas consultas sobre tablas con cientos de millones de filas tardan minutos u horas. En ClickHouse tardan segundos o fracciones de segundo. La diferencia no es de optimización: es de arquitectura.

Columnar vs filas

PostgreSQL almacena los datos por filas. Cuando lees un registro, se lee toda la fila completa del disco: id, nombre, email, dirección, teléfono, fecha de registro, todo. Si solo necesitas el email, da igual: se lee todo.

ClickHouse almacena los datos por columnas. Cada columna es un fichero separado en disco. Si tu consulta solo necesita country y duration, solo lee esas dos columnas. Las otras ni las toca. En una tabla con 50 columnas y 100 millones de filas, la diferencia de IO es brutal.

Además, los datos de una misma columna se comprimen mucho mejor que los de una fila completa. Una columna de países tiene valores repetidos (España, España, Francia, España...) que se comprimen al 5-10% de su tamaño original. Una tabla de 100GB en PostgreSQL puede ocupar 10-15GB en ClickHouse.

Lo que se mantiene

El SQL de ClickHouse es muy parecido al de PostgreSQL:

SELECT
  country,
  toStartOfHour(created_at) AS hour,
  count() AS calls,
  avg(duration) AS avg_duration
FROM calls
WHERE created_at >= '2026-04-01'
GROUP BY country, hour
ORDER BY calls DESC
LIMIT 20;

Si sabes SQL, sabes ClickHouse. Los JOIN, GROUP BY, HAVING, ORDER BY, subqueries, CTEs... todo funciona. Las funciones cambian de nombre (PostgreSQL usa date_trunc, ClickHouse usa toStartOfHour) pero el concepto es el mismo.

Lo que cambia radicalmente

No hay UPDATE ni DELETE eficientes

En PostgreSQL haces UPDATE users SET name = 'Juan' WHERE id = 42 y funciona en milisegundos. En ClickHouse, ALTER TABLE ... UPDATE es una operación pesada que reescribe partes enteras de la tabla. No está diseñado para eso.

ClickHouse es append-only por diseño. Los datos se insertan y se consultan. Si necesitas "borrar" un dato, lo marcas como borrado y lo filtras en las consultas, o usas ReplacingMergeTree que elimina duplicados en background.

Los inserts son en batch

En PostgreSQL insertas fila a fila sin problema. En ClickHouse, insertar fila a fila es un antipatrón que puede destrozar el rendimiento. ClickHouse espera batches de miles o cientos de miles de filas por insert.

-- Esto es correcto
INSERT INTO events (timestamp, type, data)
VALUES
  ('2026-04-08 10:00:00', 'click', '{"page": "/"}'),
  ('2026-04-08 10:00:01', 'click', '{"page": "/about"}'),
  -- ... cientos de filas más

La regla general: inserta al menos una vez por segundo con al menos 1000 filas por batch. Si tienes eventos en tiempo real, acumúlalos en un buffer y haz flush periódico.

MergeTree y la clave de ordenación

En PostgreSQL creas una tabla y luego añades índices. En ClickHouse, la clave de ordenación (ORDER BY en la definición de la tabla) es la decisión más importante que vas a tomar:

CREATE TABLE calls (
  created_at DateTime,
  country String,
  customer_id UInt32,
  duration UInt16
) ENGINE = MergeTree()
ORDER BY (country, created_at);

La clave de ordenación determina cómo se organizan los datos en disco. Las consultas que filtran por los primeros campos de la clave son rápidas. Las que filtran por campos que no están en la clave tienen que escanear más datos.

Piensa en la clave de ordenación como un índice que siempre está ahí y que define la estructura física de los datos. No puedes añadirlo después: tienes que elegirlo al crear la tabla.

Cuándo usar ClickHouse

• Logs y eventos: millones de registros por día, consultas analíticas sobre periodos de tiempo.
• Métricas y monitorización: series temporales con agregaciones por minuto/hora/día.
• Analytics de producto: quién hace qué, cuándo, cuántas veces.
• Facturación por uso: calcular consumos sobre registros de llamadas, API calls, etc.

Cuándo NO usar ClickHouse

• Aplicaciones transaccionales: si necesitas UPDATE y DELETE frecuentes, usa PostgreSQL.
• Pocos datos: si tu tabla tiene menos de un millón de filas, PostgreSQL es más que suficiente.
• Consultas por clave primaria: si tus consultas son "dame el usuario 42", PostgreSQL con un índice es instantáneo. ClickHouse no está optimizado para eso.
• ACID estricto: ClickHouse no garantiza transacciones en el sentido clásico.

La combinación ganadora

En los proyectos donde uso ClickHouse, siempre va acompañado de PostgreSQL. PostgreSQL lleva la operativa: usuarios, configuración, estado de la aplicación. ClickHouse lleva el analytics: logs, CDRs, métricas, eventos.

La aplicación escribe en ambas bases de datos. Las consultas transaccionales van a PostgreSQL. Los dashboards, reportes y análisis van a ClickHouse. Cada base de datos hace lo que mejor sabe hacer.

No es más complejo de lo que parece. Es una conexión más en tu aplicación. Y la primera vez que una consulta que tardaba tres minutos en PostgreSQL se ejecuta en 200 milisegundos en ClickHouse, todo el esfuerzo merece la pena.