Historiador de datos vs base de datos de series temporales: cuál elegir

Un historiador de datos clásico y una base de datos de series temporales (TSDB) resuelven la misma necesidad: guardar años de señales de planta con marca de tiempo y servirlas rápido. La diferencia no está en la función sino en el origen, el modelo de licencia, el ecosistema y el equipo que hace falta para operarlos. Esta comparativa ordena esos criterios para que la decisión sea de ingeniería y no de inercia, y explica por qué en una plataforma de datos bien diseñada el motor concreto es la pieza más fácil de cambiar.

Dos familias para el mismo problema

El patrón de datos de una planta es peculiar: muchísimos valores pequeños, ordenados por tiempo, que nunca se modifican después de escribirse. Sobre ese patrón han crecido dos familias de producto. La primera, el historiador de datos clásico, nació dentro del mundo de la automatización: lo venden los grandes fabricantes industriales, se integra de forma nativa con sus SCADA y sus herramientas cliente, y se licencia habitualmente por número de señales. La segunda, la base de datos de series temporales, nació en el mundo del software: proyectos de código abierto y productos cloud pensados para cualquier dato con marca de tiempo, desde métricas de servidores hasta sensores industriales.

Qué guarda exactamente ese histórico (tags, indicadores de calidad, compresión, deadband) y cómo dimensionarlo lo tratamos en la guía de historian industrial. Aquí asumimos que ya sabes que necesitas uno y la pregunta es cuál de las dos familias elegir.

Qué es cada uno, en dos párrafos

El historiador clásico es un producto industrial llave en mano. Ejemplos representativos son AVEVA PI System o Proficy Historian de GE Vernova, que sus fabricantes presentan como historiadores de datos de planta para entornos de operación. Llega con conectores para los protocolos y SCADA de su ecosistema, herramientas cliente maduras para tendencias e informes, y soporte de fabricante. A cambio, el coste de licencia crece con el número de tags y la flexibilidad de despliegue e integración fuera de su ecosistema es menor.

La base de datos de series temporales es un motor de almacenamiento especializado, no un producto industrial cerrado. Ejemplos representativos son InfluxDB o TimescaleDB, ambos con versiones de código abierto según sus propias webs. Ofrece escritura masiva, compresión de series temporales y un lenguaje de consulta con agregados por ventana, y se despliega donde se quiera: un servidor en planta, un contenedor, la nube. A cambio, no trae conectores industriales ni herramientas cliente de planta: la captura, la visualización y la gestión de tags las tiene que aportar la plataforma que la rodea.

Comparativa: historiador de datos vs TSDB

Criterio	Historiador clásico	Base de series temporales
Origen	Mundo de la automatización industrial	Mundo del software y la infraestructura
Qué compras	Producto completo: motor, conectores y herramientas cliente	Solo el motor de almacenamiento y consulta
Licencia	Comercial, habitualmente escalada por número de tags	Código abierto en su versión base; ediciones comerciales opcionales
Conectividad industrial	Nativa dentro del ecosistema del fabricante	No incluida: la aporta la capa edge o la plataforma
Flexibilidad de despliegue	Condicionada por los requisitos del producto	Alta: servidor local, contenedor, nube o híbrido
Integración con terceros	A través de las interfaces que el fabricante ofrece	APIs abiertas y ecosistema amplio de librerías
Equipo necesario	Perfil de automatización, formado en el producto	Perfil de TI o de plataforma, o un integrador que lo opere
Riesgo principal	Dependencia del fabricante y coste creciente por tag	Montar y mantener las piezas que el producto cerrado ya trae

Cuándo tiene sentido el historiador clásico

Cuando la planta ya vive dentro del ecosistema de un fabricante, el historiador de ese fabricante es el camino de menor fricción: los conectores existen, las herramientas cliente son conocidas y el soporte responde de la cadena completa. También pesa el factor organizativo: si el equipo que va a operar el histórico es de automatización y no hay perfil de TI que mantenga infraestructura de software, un producto cerrado con soporte de fabricante reduce riesgo. La contrapartida es estructural: el coste escala con los tags, lo que en la práctica empuja a historizar menos señales de las debidas, y la integración con sistemas de fuera del ecosistema depende de las interfaces que el fabricante decida ofrecer.

Cuándo tiene sentido una base de series temporales

Cuando el histórico nace dentro de una plataforma de datos, la TSDB encaja de forma natural: la conectividad industrial ya la resuelve la capa edge, la visualización ya la resuelve la capa de consumo, y lo que se necesita del motor es exactamente lo que la TSDB hace bien: escribir mucho, comprimir bien y consultar rápido por rangos. Sin coste de licencia por tag, la decisión de qué historizar deja de ser económica y pasa a ser de ingeniería: se guarda todo lo que tiene valor. Es el enfoque que aplicamos en Captia Connect, que persiste las señales normalizadas en InfluxDB dentro de despliegues locales, híbridos o cloud. La contrapartida también es real: la TSDB sola no es un histórico de planta; exige una capa de captura, un modelo de tags y una operación que alguien tiene que montar y mantener, sea el equipo propio o un integrador.

El criterio que manda: la plataforma, no el motor

La comparativa anterior tiene trampa si se lee de forma aislada: plantea la decisión como si el motor de almacenamiento fuese el centro de la arquitectura, y no debería serlo. En una plataforma de datos industriales por capas, el histórico es un consumidor más del flujo normalizado: se suscribe a lo que publica la capa edge y persiste. Si el modelo de tags, la normalización y los contratos con el resto de sistemas viven en la plataforma y no dentro del producto de histórico, cambiar de motor dentro de unos años es un proyecto acotado. Si viven dentro del historiador, cambiar es una migración de todo.

Por eso la pregunta útil no es qué motor es mejor, sino qué arquitectura deja la puerta abierta. Un historiador clásico dentro de una plataforma bien desacoplada es una opción legítima; una TSDB convertida en integrador universal repite los mismos errores que la guía de historian describe. La pieza que no conviene delegar es la de arriba: el modelo de datos común y la capa que lo sirve a operación y a negocio.

Preguntas frecuentes

¿Un historiador de datos y una TSDB son lo mismo?

Funcionalmente cumplen el mismo papel: escribir de forma masiva valores con marca de tiempo y consultarlos rápido por rangos. Se diferencian en lo que rodea al motor: el historiador clásico es un producto industrial completo con conectores y herramientas cliente, y la TSDB es solo el motor, pensado para integrarse dentro de una plataforma que aporta el resto.

¿Puedo sustituir mi historiador de fabricante por una TSDB?

Técnicamente sí, pero el motor es la parte pequeña del proyecto. Lo que determina el esfuerzo es cuánta lógica vive hoy dentro del historiador: conectores, modelo de tags, cálculos, informes y aplicaciones que consultan directamente. Lo habitual es no migrar de golpe, sino levantar la plataforma en paralelo, historizar en ella lo nuevo y decidir con calma qué histórico antiguo merece trasladarse.

¿La licencia por tag es tan determinante como parece?

Su efecto más caro no es la factura, es el comportamiento que induce: cuando cada señal cuesta dinero, se historiza lo mínimo, y las señales descartadas hoy son los análisis imposibles de dentro de tres años. Con un motor sin coste por tag la decisión de qué guardar se toma con criterio de proceso, que es donde debe estar.

¿Qué necesita una TSDB para funcionar como histórico de planta?

Tres piezas alrededor del motor: una capa de captura multiprotocolo con buffering local para que los cortes de red no abran huecos, una convención de nombres y un modelo de tags compartidos, y una capa de consumo que sirva tendencias, dashboards e informes a quien los necesita. Es exactamente la estructura de una plataforma de datos industriales por capas.

Si estás valorando cómo historizar las señales de tu planta sin atarte a un coste por tag, en Captia Connect desplegamos la cadena completa: captura multiprotocolo en el edge, buffering local y persistencia en series temporales dentro de una plataforma de datos industriales que sirve el dato a operación y a negocio. El primer paso es un inventario de señales y protocolos.