Técnico
ClickHouse 26.9 frente a PostgreSQL: eventos y límite
Cuándo separar eventos analíticos en ClickHouse y cuándo sostener PostgreSQL. Flujo, permisos, backup, costos y prueba mínima sin duplicar definiciones.
Un millón de eventos por día pesa distinto en ClickHouse 26.9 que en PostgreSQL 18. En una bodega exportadora, cada lectura de balanza, sensor y remito puede convertirse en una fila que gerencia quiere consultar rápido. Esta guía compara dónde guardar eventos, dónde conservar operaciones y cómo probar costo, permisos y recuperación antes de mover datos.
Dónde aparece el costo de mezclar eventos y operación PostgreSQL sirve muy bien para pedidos, usuarios, estados y auditoría.
El problema aparece cuando la misma base empieza a recibir millones de eventos de lectura, tracking o telemetría y los reportes compiten con la operación diaria. La factura visible no siempre es licencia: puede ser disco, memoria, backups lentos y consultas que bloquean ventanas de cierre. ClickHouse publicó v26.9.1.1629-stable el 21 de septiembre de 2026. Su documentación lo presenta como una base columnar orientada a análisis rápido sobre grandes volúmenes. PostgreSQL 18, por su parte, documenta particionamiento declarativo, rangos, listas y hash para tablas grandes, y mantiene tres familias de backup: dump SQL, copia de archivos y archivado continuo. La escala general confirma que SQL sigue en el centro del trabajo técnico: la encuesta Stack Overflow 2025 muestra SQL con 58,6% de uso entre todos los encuestados y PostgreSQL con 55,6% en bases de datos. Separar analítica y operación no elimina SQL; lo ordena por carga, consulta y recuperación. El objeto concreto es una tabla de eventos llamada lecturas_porton con fecha, patente, báscula, lote y resultado de validación. Si esa tabla queda dentro de la base transaccional y crece sin política de retención, cada backup nocturno lleva más datos de los que la operación necesita para facturar mañana. El encargado de logística necesita consultar desvíos por turno sin frenar el sistema que emite remitos.
Cómo funciona por dentro
El flujo mínimo tiene siete pasos. Primero, la aplicación operativa guarda pedido, remito, usuario y estado en PostgreSQL. Segundo, cada lectura o evento se envía a una cola o API de ingesta. Tercero, ClickHouse recibe eventos con columnas estables: fecha, origen, entidad, métrica y etiquetas. Cuarto, PostgreSQL conserva el registro de verdad para operaciones; recibe cambios con reglas de consistencia y entrega consultas por entidad. Quinto, ClickHouse guarda eventos en formato columnar; recibe lotes y devuelve agregados rápidos por fecha, origen o lote. Sexto, Metabase o Superset consulta vistas separadas: operación desde PostgreSQL, tendencias desde ClickHouse. Séptimo, backup copia ambas capas y la prueba restaura una operación y una consulta analítica. Los permisos se separan por función. Administración lee tableros; logística consulta eventos propios; IT administra ingesta y retención; soporte no borra particiones ni tablas. La señal de falla aparece cuando un usuario puede editar eventos históricos que ya alimentaron un reporte.
Qué se instala o configura primero
El primer alcance instala PostgreSQL 18 para operación, ClickHouse 26.9 para eventos, un proceso de ingesta, tablero de prueba, monitoreo de disco y backup. Con dólar oficial venta de ARS 1535, un piloto puede ubicarse entre USD 800 y USD 1.900, es decir entre ARS 1.228.000 y ARS 2.916.500. Incluye esquema inicial, ingesta de 30 días, dos tableros, roles, backup y restauración. No incluye migración histórica completa ni alta disponibilidad. UMSA puede arrancar con un dataset chico: 3 fuentes de eventos, 10 millones de filas sintéticas o históricas, 5 consultas críticas y una comparación de tiempos. El entregable verificable es un informe con tamaño en disco, duración de backup, tiempo de consulta y resultado comparado contra PostgreSQL. Una nota previa sobre DuckDB en pymes ayuda a ubicar el límite. DuckDB resuelve análisis local sobre archivos; ClickHouse entra cuando la consulta tiene usuarios concurrentes, datos vivos y retención más larga.
Dónde se rompe y cómo probarlo
El primer riesgo es duplicar definiciones. La señal aparece cuando PostgreSQL calcula entregas por fecha de remito y ClickHouse por fecha de evento. La prueba ejecuta cinco consultas de control y exige que la definición escrita acompañe cada tablero. El segundo riesgo es ingestar eventos sin idempotencia. La señal aparece cuando el mismo remito suma dos veces. La prueba reenvía un lote y revisa clave de deduplicación o marca de lote. El tercer riesgo es descuidar restauración. La documentación de ClickHouse cubre backup y restore; PostgreSQL también separa enfoques de backup. La prueba recupera una base de ensayo, corre una consulta histórica y compara conteos. El cuarto riesgo es mover datos sensibles sin permiso. La prueba crea un usuario de logística, intenta leer eventos de otra unidad y exige rechazo. La decisión práctica: medir una consulta cara antes de comprar hardware nuevo. Un ensayo de una semana alcanza para comparar tiempos, tamaño de backup y costo operativo con datos que el equipo ya entiende.
