ClickHouse 26.5 frente a PostgreSQL 18: eventos y límite

Guardar 90 días de eventos en la misma base transaccional puede costar más que separar lectura y retención. ClickHouse v26.5.6.64-stable, publicado el 23 de julio, sirve para consultas analíticas de alto volumen; PostgreSQL 18 sigue a cargo de usuarios, estados y operaciones. Esta guía muestra cuándo dividir datos, qué permisos aplicar y cómo probar que la consulta vuelve.

Dónde aparece la tabla de eventos eterna

El antagonista es la tabla de eventos eterna: login, cambio de estado, impresión, exportación, error de integración y consulta de tablero viviendo en la misma base dónde se cargan facturas o turnos. En una municipalidad chica del Gran Mendoza, el síntoma llega cuando el reporte de atención tarda más que la consulta de un expediente. Un disco NVMe con luz ámbar en el servidor deja de ser detalle técnico y pasa a explicar el costo. La cifra externa ayuda a ordenar la decisión: Stack Overflow 2025 reunió más de 49.000 respuestas de 177 países y ubicó a PostgreSQL como una tecnología central entre bases de datos. Esa adopción no convierte a PostgreSQL en depósito infinito de eventos; la documentación oficial de particionado avisa que la ventaja aparece cuando una tabla supera la memoria física del servidor. La consulta lenta dejó de ser una molestia y pasó a ser una factura diaria.

Cómo funciona por dentro

El flujo mantiene dos responsabilidades separadas. PostgreSQL 18 guarda registros transaccionales: usuarios, permisos, facturas, expedientes, estados y auditoría corta. ClickHouse guarda eventos anexos en tablas MergeTree: fecha, actor, acción, objeto, latencia, IP y resultado. La aplicación escribe el estado principal en PostgreSQL y envía un evento de solo agregado hacia ClickHouse. Metabase o Superset consulta ClickHouse para reportes de volumen y PostgreSQL para datos de gestión. 1. La aplicación guarda la operación principal en PostgreSQL. 2. Un proceso agrega evento, fecha, actor y resultado. 3. ClickHouse recibe eventos en una tabla MergeTree por fecha. 4. Los permisos separan escritor de eventos, lector de tablero y administrador. 5. TTL elimina o mueve eventos viejos según política. 6. El backup conserva PostgreSQL completo y exporta eventos críticos. 7. Una prueba recrea un reporte con datos restaurados. MergeTree ordena y parte datos para lectura rápida por columnas. TTL aplica reglas de vida útil para borrar o mover registros cuando vence la retención. PostgreSQL queda para consistencia, claves y transacciones; ClickHouse queda para lectura agregada. Si ClickHouse falla, la operación diaria sigue, y los eventos se reenvían desde una cola o archivo de contingencia.

Qué se instala o configura primero

El piloto empieza con una tabla de eventos acotada: fecha, actor, módulo, acción, entidad, resultado y duración. Se instala ClickHouse 26.5, PostgreSQL 18, un usuario de escritura para eventos y un usuario de lectura para tableros. El primer entregable verificable es un reporte de 30 días con cantidad de operaciones, errores por módulo y percentil de duración. El costo se mide por carga real. Con dólar oficial vendedor a ARS 1.510, un servidor de pruebas de USD 48 mensuales más USD 8 de almacenamiento queda cerca de ARS 84.560 por mes. Un piloto de 18 a 26 horas a USD 30/h queda entre USD 540 y USD 780, es decir entre ARS 815.400 y ARS 1.177.800. Incluye instalación, ingestión, permisos, retención, backup y restauración. Quedan fuera limpieza histórica y rediseño de reportes heredados. La revisión final compara el reporte nuevo contra una consulta SQL vieja para confirmar diferencia de tiempo, cantidad de filas y criterio de conteo. UMSA puede aplicar este patrón cuando una organización ya tiene PostgreSQL y necesita medir actividad sin bloquear la base de operación. La decisión se valida con un reporte que tarde segundos y con una restauración que conserve el período pactado.

Dónde se rompe y cómo probarlo

El primer riesgo es duplicar verdad. Si un estado operativo vive en ClickHouse y PostgreSQL, los reportes compiten. La prueba define qué campos son transaccionales y rechaza cualquier evento usado para modificar saldos, permisos o vencimientos. El segundo riesgo es retención mal escrita. La señal aparece cuando TTL borra eventos que auditoría necesita. La prueba carga eventos con fechas simuladas, ejecuta la política y verifica qué registros quedaron, cuáles salieron y quién aprobó la regla. El tercer riesgo es backup incompleto. PostgreSQL puede restaurar operaciones, y ClickHouse puede perder el historial analítico si nadie exporta datos críticos. La prueba restaura PostgreSQL, carga una muestra de eventos exportados y reconstruye el reporte mensual. La separación sirve cuando el equipo puede decir qué dato vive en cada motor, qué usuario lo lee y qué evidencia queda si el tablero falla.

Para seguir leyendo

• Motor MergeTree en ClickHouse
• TTL para borrar o mover datos en ClickHouse
• Particionado de tablas en PostgreSQL 18 para bases transaccionales
• Barman 3.19 en PostgreSQL: WAL, retención y restauración