¿Qué hace diferente a una base de datos de series temporales y cuándo hace falta una de verdad?

#La forma de los datos de series temporales

Los datos de series temporales tienen un patrón de acceso distintivo, muy diferente al de los datos OLTP típicos, y esa diferencia es la razón de ser de las bases de datos especializadas en ellos:

• Intensivos en escritura, de solo-anexado. Llegan puntos nuevos constantemente (uno por métrica por intervalo, uno por evento), y casi nunca se actualizan después de escritos — no vuelves a editar la lectura de uso de CPU de ayer.
• El tiempo siempre está en la consulta. Casi toda consulta filtra o agrupa por un rango de tiempo: "uso de CPU del host X en la última hora," "latencia p99 por endpoint en las últimas 24 horas." Un esquema y una estrategia de índices que no estén construidos alrededor de ese patrón de acceso desperdician esfuerzo optimizando consultas que nadie ejecuta.
• Alta cardinalidad, alto volumen, vida útil corta por punto. Un solo servicio que emite 50 métricas etiquetadas por host, región y endpoint puede producir millones de series distintas, cada una marcando cada pocos segundos — y un solo punto crudo de hace seis meses rara vez se consulta a resolución completa; lo que quieres es la tendencia, no la muestra exacta.
• Los datos viejos importan menos, de una forma específica. Los datos recientes necesitan ser rápidos de escribir y rápidos de consultar a resolución completa; los datos viejos necesitan ocupar mucho menos espacio y pueden tolerar estar pre-agregados (rollup) a una resolución más gruesa, o eliminarse por completo.

#Qué hace mal aquí una base de datos relacional genérica

Nada impide poner datos de series temporales en Postgres? o MySQL — muchísimos sistemas lo hacen, especialmente a escala moderada, y extensiones de Postgres como TimescaleDB existen precisamente para añadir comportamiento de series temporales a un motor relacional en vez de reemplazarlo. Pero, de forma ingenua, algunas cosas fallan a escala:

• Un índice B-tree sobre (sensor_id, timestamp) crece linealmente para siempre y nunca se encoge por sí solo; no hay un concepto integrado de "estos datos son viejos, comprímelos o elimínalos."
• El almacenamiento orientado a filas hace que una consulta como "temperatura promedio por hora entre un millón de sensores" tenga que leer todas las columnas de todas las filas aunque solo necesite dos — un desperdicio enorme de I/O.
• La retención hay que armarla a mano: un cron? job que corre DELETE FROM readings WHERE ts < now() - interval '90 days', que a su vez genera muchas tuplas muertas/WAL y necesita vacuum, sobre una tabla que se está escribiendo constantemente.
• No hay un concepto nativo de downsampling — hay que escribir tus propios jobs programados para pre-calcular rollups por hora/día si quieres dashboards rápidos sobre rangos largos.

#Qué te da una base de datos de series temporales construida para esto

Sistemas como InfluxDB, TimescaleDB (Postgres + extensión), Prometheus (específicamente para métricas) y ofertas en la nube como Amazon Timestream o el Managed Service for Prometheus de Google Cloud incorporan lo siguiente como funciones de primera clase, en vez de patrones que tienes que construir tú mismo:

• Almacenamiento columnar o amigable con columnas para el caso de series temporales, de forma que las consultas agregadas sobre rangos largos solo tocan las columnas y buckets de tiempo que realmente necesitan, y comprimen extremadamente bien (lecturas sucesivas del mismo sensor suelen tener valores cercanos — ideal para codificación delta/run-length).
• Particionamiento automático por tiempo (chunks/shards por día o por semana), de forma que los chunks viejos se pueden comprimir, mover a almacenamiento más barato o eliminar como una operación de metadatos en vez de un DELETE fila por fila.
• Downsampling/agregados continuos integrados — un rollup que mantiene "promedio por hora" o "máximo por día" de forma incremental a medida que llegan datos crudos nuevos, de forma que un dashboard que consulta un año de datos golpea filas pre-agregadas en vez de escanear un año de puntos crudos.
• Políticas de retención como configuración — "guardar datos crudos 7 días, rollups de 1 minuto 90 días, rollups por hora para siempre" declarado una sola vez, aplicado automáticamente.

#Cuándo hace falta una de verdad — y cuándo no

La respuesta honesta es: no tan pronto como sugiere el hype. Si tu volumen es unas pocas métricas por minuto por servicio y una ventana de retención modesta, Postgres con un índice sensato y una tabla de rollup manual te va a servir cómodamente durante mucho tiempo, y conservas la enorme ventaja de tener una tecnología de base de datos menos que operar, respaldar y dotar de personal. Las señales que de verdad justifican migrar son:

1. Cardinalidad/volumen que supera el throughput de escritura cómodo de tu base de datos OLTP — millones de series distintas, o tasas de escritura que empiezan a competir con tu carga transaccional por el mismo ancho de banda de I/O y WAL.
2. Necesitas políticas de retención/downsampling que actualmente armas a mano con cron jobs, y esos jobs se están volviendo su propia carga de mantenimiento o a veces afectan la carga de producción.
3. Tus consultas son fundamentalmente agregados por rango de tiempo (percentiles, tasas, promedios móviles) en vez de búsquedas puntuales o joins entre muchas entidades — esta es la forma de consulta para la que están optimizados los motores de series temporales, y donde el planificador de consultas de propósito general de un motor relacional empieza a perder.
4. Estás construyendo infraestructura de observabilidad en sí misma (métricas, trazas) en vez de guardar datos de negocio con marca de tiempo — los sistemas estilo Prometheus son casi obligatorios ahí porque todo el ecosistema (Grafana, alerting, exporters) asume esa forma.