ClickHouse frente a PostgreSQL: eventos, costo y límite
ClickHouse sirve para eventos y consultas analíticas de alto volumen. Cómo separarlo de PostgreSQL, fijar permisos, calcular costo y probar restauración.
Guardar cada evento de una aplicación en PostgreSQL puede costar más que separar la consulta analítica desde el primer mes del equipo. ClickHouse entra cuando reportes, logs de uso o métricas leen millones de filas que la base transaccional necesita para facturar y cobrar. Esta guía explica qué dato mueve cada motor, cuánto cuesta empezar y dónde se prueba la salida.
Dónde aparece la presión sobre la base
El síntoma se repite: la aplicación cobra, emite turnos o registra pedidos; el reporte semanal pide sumar eventos por usuario, día, campaña o sede. La consulta se vuelve lenta y compite con la operación. Un encargado de sistemas mira una barra de progreso detenida mientras la mesa de ayuda pregunta si el sistema está caído. La presión crece cuando cada nuevo filtro obliga a leer más historial. La cifra que ordena el debate viene de la encuesta Stack Overflow 2025: SQL fue usado por 58,6 % de los encuestados y PostgreSQL por 55,6 % entre bases de datos. La base transaccional es conocida y útil; el problema aparece cuando se le pide hacer de archivo de eventos y de caja diaria al mismo tiempo. ClickHouse se ubica en ese borde. Su guía de inicio rápido muestra una base orientada a consultas analíticas. El antagonista concreto es la tabla de eventos que crece sin retención y termina frenando cierres, reportes y búsquedas.
Cómo funciona por dentro
El flujo tiene seis pasos. La aplicación guarda facturas, usuarios, permisos y estados en PostgreSQL. Cada acción analítica crea un evento con usuario, entidad, hora, tipo, origen y metadatos mínimos. Un proceso de salida agrupa esos eventos y los inserta en ClickHouse por lotes. PostgreSQL conserva el dato que manda la operación: facturas, pagos, turnos, permisos y auditoría. ClickHouse guarda eventos de lectura intensiva: visitas, clics, cambios de estado, mediciones o logs de negocio. La familia MergeTree está pensada para inserciones altas y grandes volúmenes; cada inserción crea partes que luego se mezclan en segundo plano. Grafana o Metabase consultan ClickHouse con un usuario de solo lectura. La guía oficial del plugin de ClickHouse para Grafana recomienda crear un usuario lector antes de definir la fuente de datos. Gerencia ve métricas; IT ve latencia, inserciones fallidas y tamaño por partición. Los permisos importan porque un evento puede tener datos personales. La aplicación escribe; analistas leen vistas agregadas; soporte consulta un evento solo si tiene ticket. El borrado se maneja por retención y particiones, con una regla escrita antes de cargar datos reales. El backup separa responsabilidades. PostgreSQL necesita restauración transaccional. ClickHouse necesita recuperar tablas analíticas, particiones y configuración. La guía de backup de ClickHouse cubre enfoques para respaldar datos y metadatos; la prueba útil restaura un día y compara un indicador publicado.
Qué se instala o configura primero
La pila mínima tiene PostgreSQL 17, ClickHouse en un servidor separado, un proceso de carga por lotes, Grafana con usuario de solo lectura y un tablero de salud. El primer entregable verificable es una consulta que suma eventos por día sin tocar las tablas transaccionales. Con Banco Nación como referencia del 14 de junio de 2026, USD 1 vendedor figura a ARS 1.450. Un servidor de USD 45 a 90 mensuales queda entre ARS 65.250 y ARS 130.500. La implementación inicial suele pedir 25 a 45 horas: elegir eventos, escribir esquema, armar carga, crear usuarios, fijar retención y probar restauración. UMSA puede aplicar este patrón cuando un tablero empieza a pedir métricas de uso o trazabilidad de negocio sobre una aplicación propia. El entregable útil es una consulta pesada que deja de molestar a la operación y un documento que dice qué se borra, cuándo y quién lo autoriza.
Dónde se rompe y cómo probarlo
El primer riesgo es duplicar estados. Si una factura aparece en PostgreSQL y en ClickHouse con dos valores distintos, el reporte pierde autoridad. La prueba toma diez facturas cerradas y verifica que ClickHouse solo tenga eventos derivados, nunca el estado maestro editable. El segundo riesgo es cargar eventos sin reloj confiable. La señal aparece cuando un usuario genera actividad fuera de orden. La prueba inserta eventos con hora de cliente y hora de servidor; el tablero debe ordenar por hora de servidor y conservar la original como dato auxiliar. El tercer riesgo es una retención mal escrita. La señal es una partición antigua que sigue creciendo o una partición nueva borrada antes de cerrar el mes. La prueba carga datos de dos meses, ejecuta la política de retención y compara totales esperados. El cuarto riesgo es una consulta sin límite. La señal aparece cuando un tablero permite leer todo el historial por accidente. La prueba exige filtros de fecha y rechaza consultas abiertas desde usuarios de análisis. ClickHouse ayuda cuando cada evento tiene dueño, vencimiento y prueba de restauración. Sin esas tres condiciones, solo se movió el costo a otro servidor.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.