# Bases de datos de series temporales desde cero

**Categoría:** Bases de datos · **Nivel:** Intermedio · **Lectura:** 20 min
**Publicada:** 2026-07-28 · **Actualizada:** 2026-07-28 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/bases-de-datos/bases-de-datos-de-series-temporales-desde-cero/

## Respuesta rápida

Una **base de datos de series temporales** (*time series database* o TSDB) es una base de datos especializada en guardar y consultar datos que llegan **con una marca de tiempo** y que se acumulan en el orden en que ocurren: la temperatura de un sensor cada segundo, el uso de CPU de un servidor cada 10 segundos, el precio de una acción cada minuto, los clics en una web. A cada uno de esos datos —un valor más su instante— se lo llama **punto**, y una secuencia de puntos del mismo origen a lo largo del tiempo es una **serie**. Lo que tienen en común estos datos es un patrón muy particular: **se escriben constantemente y en enormes cantidades** (un sensor genera millones de puntos al día), **casi nunca se modifican** una vez escritos (un dato del pasado no cambia), y **se consultan por rangos de tiempo** («la media de CPU de la última hora», «la temperatura de ayer»). Una base de datos [relacional](../relacional-vs-no-relacional/index.md) normal puede almacenar esto, pero **sufre** cuando el volumen crece: no está optimizada para tragar millones de inserciones por segundo, sus [índices](../indices-en-bases-de-datos-como-aceleran-las-consultas/index.md) se hinchan, las tablas se vuelven gigantescas y las consultas por rango se ralentizan. Las bases de datos de series temporales hacen tres cosas distintas para resolverlo: están **optimizadas para escrituras masivas** en orden temporal; **comprimen** los datos de forma agresiva aprovechando que los valores consecutivos se parecen mucho (dos lecturas seguidas de un termómetro casi no cambian); y ofrecen funciones nativas para **agregar por ventanas de tiempo** («dame el promedio por minuto») y para **caducar datos viejos** automáticamente (borrar lo de hace más de 30 días). Las herramientas más conocidas son **InfluxDB** (una TSDB dedicada), **TimescaleDB** (una extensión que le da superpoderes de series temporales a PostgreSQL, así que seguís usando SQL) y **Prometheus** (centrada en monitorización de sistemas, muy usada con **Grafana** para los gráficos). ¿Cuándo usar una? Cuando tengas **métricas, sensores IoT o monitorización** que generan datos con marca de tiempo en gran volumen. ¿Cuándo no? Para datos de negocio normales —usuarios, pedidos, facturas— que se leen y modifican de mil maneras: ahí una base relacional sigue siendo lo correcto.

## Qué es una serie temporal

Una **serie temporal** es una secuencia de datos donde cada dato lleva pegada la **marca de tiempo** del instante en que se produjo, y los datos se acumulan en el orden en que van ocurriendo. Este tipo de dato está por todas partes en cuanto uno se fija: cada medición de un sensor, cada métrica de un servidor, cada precio de un mercado, cada evento registrado.

> **Puntos, series y un patrón muy particular**
>
> El vocabulario básico es simple. A cada dato individual —un **valor** más el **instante** en que se midió— se lo llama **punto** (por ejemplo: «23,4 °C a las 14:05:03»). Una secuencia de puntos del mismo origen a lo largo del tiempo es una **serie** (por ejemplo, todas las lecturas de *ese* termómetro concreto). Lo que hace especiales a estos datos no es su forma, sino su **patrón de uso**, que es muy distinto al de los datos normales de una aplicación. Primero, se **escriben constantemente y en cantidades enormes**: un solo sensor que mide una vez por segundo genera más de 86.000 puntos al día, y una instalación con miles de sensores o servidores produce millones o miles de millones. Segundo, **casi nunca se modifican**: una vez que se registra que a las 14:05 la temperatura era 23,4 °C, ese dato del pasado *no cambia*; solo se añaden datos nuevos, no se editan los viejos. Tercero, **se consultan por rangos de tiempo y de forma agregada**: rara vez interesa un punto suelto; lo que se pregunta es «la media de la última hora», «el máximo de ayer», «la evolución de la última semana». Este patrón —escritura masiva, sin modificaciones, lectura por rangos— es tan característico que justifica una base de datos diseñada específicamente para él.

## Por qué una BD normal sufre

Una base de datos relacional *puede* guardar series temporales —al fin y al cabo, una tabla con una columna de fecha y otra de valor lo hace—, pero **sufre** a medida que el volumen crece. Los problemas principales:

| Problema en una BD relacional normal | Qué hace distinto una TSDB |
|---|---|
| No aguanta millones de inserciones por segundo | Optimizada para escrituras masivas en orden temporal |
| Las tablas y los índices se hinchan sin parar | Compresión agresiva de valores parecidos |
| Las consultas por rango de tiempo se ralentizan | Agregación nativa por ventanas de tiempo |
| Hay que borrar datos viejos a mano | Caducidad automática de datos antiguos |

> **Atención**
>
> La ventaja más llamativa de una base de datos de series temporales es la **compresión**, y se apoya en una observación simple: en una serie temporal, los **valores consecutivos se parecen muchísimo**. Dos lecturas seguidas de un termómetro que mide cada segundo apenas cambian —23,4 °C y luego 23,4 °C, o 23,5 °C—; el uso de CPU de un servidor de un instante al siguiente varía poco; y la marca de tiempo avanza en incrementos regulares y predecibles. Cuando los datos son tan parecidos entre sí, se pueden **comprimir de forma extraordinaria**: en vez de guardar cada valor entero una y otra vez, la base guarda solo las *diferencias*, que son minúsculas, y las marcas de tiempo regulares se almacenan casi gratis. En la práctica esto significa que una TSDB puede guardar la misma cantidad de puntos ocupando una fracción del espacio que necesitaría una base relacional normal, lo que a su vez hace que quepan más datos, que las consultas lean menos y vayan más rápido, y que conservar el histórico salga barato. A esta compresión se le suman las otras optimizaciones —escritura secuencial pensada para la avalancha de inserciones, y funciones para **agregar por ventanas** («promedio por minuto», «máximo por hora») directamente en la base sin traer millones de puntos crudos a la aplicación—. Juntas, estas tres cosas —escritura masiva, compresión y agregación temporal— son lo que separa a una TSDB de una tabla relacional con una columna de fecha.

## Herramientas

Hay varias bases de datos de series temporales, cada una con su enfoque. Las más conocidas:

| Herramienta | Enfoque | Cuándo encaja |
|---|---|---|
| InfluxDB | TSDB dedicada, con su propio lenguaje de consulta | Métricas y sensores IoT como caso principal |
| TimescaleDB | Extensión de PostgreSQL: seguís usando SQL | Ya usás PostgreSQL y querés series temporales sin cambiar de mundo |
| Prometheus | Centrada en monitorización de sistemas; recoge métricas | Monitorizar servidores, contenedores y aplicaciones |

> **Atención**
>
> En el mundo de la **monitorización de sistemas** es muy habitual encontrar una combinación concreta: **Prometheus** como base de datos de series temporales que *recoge* las métricas de servidores, contenedores y aplicaciones (uso de CPU, memoria, peticiones por segundo, errores), y **Grafana** como herramienta que *dibuja* esas series en paneles con gráficos, tableros y alarmas. La división de trabajo es clara: Prometheus almacena y consulta los datos; Grafana los visualiza de forma que un humano pueda entenderlos de un vistazo. Grafana, además, no está atada a Prometheus: puede leer también de InfluxDB, de TimescaleDB y de muchas otras fuentes, así que es la capa de visualización estándar de facto para series temporales, sea cual sea la base que haya debajo. Para quien empieza, la elección entre herramientas se puede resumir así: si ya usás [PostgreSQL](../relacional-vs-no-relacional/index.md) y no querés aprender un mundo nuevo, **TimescaleDB** te da series temporales manteniendo el SQL de siempre; si tu caso son sensores o métricas y querés una herramienta dedicada, **InfluxDB**; y si lo tuyo es monitorizar infraestructura, **Prometheus con Grafana** es el camino más transitado. En todos los casos, lo importante es reconocer *que* tus datos son series temporales: a partir de ahí, cualquiera de estas herramientas te evitará el sufrimiento de forzar una base relacional a hacer un trabajo para el que no fue diseñada.

## Cuándo usarlas (y cuándo no)

- **Sí:** métricas de sistemas —CPU, memoria, peticiones— que se recogen sin parar.
- **Sí:** sensores IoT y telemetría que generan datos con marca de tiempo en gran volumen.
- **Sí:** datos financieros o de mercado con muchas mediciones a lo largo del tiempo.
- **No:** datos de negocio normales —usuarios, pedidos, facturas— que se leen y modifican de mil maneras; ahí va una BD relacional.
- **No:** datos que se editan con frecuencia; las TSDB asumen que el pasado no cambia.
- **Cuidado:** no meter una TSDB «por si acaso»; si el volumen es pequeño, una tabla relacional con un buen índice de fecha basta.
- **Recordá:** configurar la caducidad de datos viejos si no necesitás conservar años de histórico crudo.

## Preguntas frecuentes

**¿Qué es una base de datos de series temporales?**
Una base de datos de series temporales, conocida en inglés como time series database o TSDB, es una base de datos especializada en almacenar y consultar datos que llegan con una marca de tiempo y que se acumulan en el orden en que van ocurriendo, como la temperatura de un sensor medida cada segundo, el uso de procesador de un servidor cada pocos segundos, el precio de una acción cada minuto o los eventos registrados en una aplicación. El vocabulario básico de este tipo de datos es sencillo. A cada dato individual, formado por un valor y el instante en que se midió, se le llama punto, por ejemplo veintitrés grados y cuatro décimas a las dos y cinco de la tarde. Y a una secuencia de puntos del mismo origen a lo largo del tiempo se le llama serie, por ejemplo todas las lecturas de un termómetro concreto. Lo que hace especiales a estos datos no es su forma, que es simple, sino su patrón de uso, que es muy distinto al de los datos habituales de una aplicación. En primer lugar, las series temporales se escriben constantemente y en cantidades enormes, ya que un solo sensor que mide una vez por segundo genera más de ochenta mil puntos al día, y una instalación con miles de sensores o servidores produce millones o incluso miles de millones de puntos. En segundo lugar, casi nunca se modifican, ya que una vez registrado un dato del pasado, ese dato no cambia, y lo único que se hace es añadir datos nuevos, sin editar los viejos. En tercer lugar, se consultan por rangos de tiempo y de forma agregada, ya que rara vez interesa un punto suelto y lo que se pregunta es la media de la última hora, el máximo de ayer o la evolución de la última semana. Este patrón de escritura masiva, ausencia de modificaciones y lectura por rangos es tan característico que justifica la existencia de una base de datos diseñada específicamente para él, en lugar de forzar a una base de datos relacional normal a manejar un tipo de dato para el que no está optimizada. Las bases de datos de series temporales aplican optimizaciones concretas para este patrón, como la escritura masiva eficiente, la compresión agresiva de los datos y las funciones de agregación por ventanas de tiempo.

**¿Por qué una base de datos relacional normal sufre con series temporales?**
Una base de datos relacional normal sufre con las series temporales porque, aunque puede almacenar este tipo de datos en una tabla con una columna de fecha y otra de valor, no está optimizada para el patrón de uso tan particular de las series temporales, y a medida que el volumen de datos crece aparecen varios problemas de rendimiento. El primer problema es que una base relacional no está diseñada para tragar millones de inserciones por segundo, que es lo que puede generar una avalancha de sensores o de métricas de sistemas, de modo que la escritura se convierte en un cuello de botella. El segundo problema es que, con tal cantidad de datos, las tablas se vuelven gigantescas y los índices que aceleran las consultas se hinchan sin parar, ocupando cada vez más espacio y volviéndose más lentos de mantener. El tercer problema es que las consultas por rango de tiempo, que son las más habituales en series temporales, como pedir la media de la última hora o la evolución de la última semana, se ralentizan a medida que la tabla crece, porque la base tiene que recorrer una cantidad enorme de filas. El cuarto problema es que borrar los datos viejos, algo necesario cuando no se quiere conservar todo el histórico crudo indefinidamente, hay que hacerlo a mano y resulta costoso en una base relacional. Las bases de datos de series temporales resuelven cada uno de estos problemas con optimizaciones específicas. Frente a la escritura, están optimizadas para escrituras masivas en orden temporal, aprovechando que los datos llegan ordenados en el tiempo. Frente al tamaño, comprimen los datos de forma agresiva, aprovechando que los valores consecutivos de una serie se parecen muchísimo, ya que dos lecturas seguidas de un mismo sensor apenas cambian, lo que permite guardar solo las diferencias y almacenar la misma cantidad de puntos en una fracción del espacio. Frente a las consultas, ofrecen funciones nativas para agregar por ventanas de tiempo, como calcular el promedio por minuto o el máximo por hora directamente en la base, sin traer millones de puntos crudos a la aplicación. Y frente a los datos viejos, ofrecen mecanismos de caducidad automática que borran solos los datos más antiguos de un cierto plazo. Por todo ello, cuando el volumen de series temporales es grande, una base de datos especializada evita el sufrimiento de forzar a una relacional a hacer un trabajo para el que no fue diseñada.

**¿Qué diferencia hay entre InfluxDB, TimescaleDB y Prometheus?**
InfluxDB, TimescaleDB y Prometheus son tres de las bases de datos de series temporales más conocidas, y se diferencian sobre todo en su enfoque y en el caso de uso en el que encajan mejor. InfluxDB es una base de datos de series temporales dedicada, es decir, construida desde cero específicamente para este tipo de datos, con su propio lenguaje de consulta, y encaja bien cuando el caso principal son métricas y sensores del internet de las cosas y se quiere una herramienta especializada en series temporales. TimescaleDB tiene un enfoque distinto, ya que no es una base de datos independiente sino una extensión de PostgreSQL, que es una base de datos relacional muy popular, y lo que hace es añadirle capacidades de series temporales manteniendo el lenguaje SQL de siempre, de modo que quien ya usa PostgreSQL puede tener series temporales sin cambiar de mundo ni aprender un lenguaje nuevo, aprovechando además todo lo que ya sabe de SQL y todas las herramientas del ecosistema de PostgreSQL. Encaja bien cuando ya se usa PostgreSQL y se quiere manejar series temporales de forma eficiente sin salir de ese entorno. Prometheus, por su parte, está centrada en la monitorización de sistemas, y su enfoque es recoger métricas de servidores, contenedores y aplicaciones, como el uso de procesador, la memoria, las peticiones por segundo o los errores, de modo que encaja cuando el objetivo es monitorizar infraestructura. Es muy habitual encontrar Prometheus combinada con Grafana, una herramienta que dibuja las series temporales en paneles con gráficos, tableros y alarmas, en una división de trabajo en la que Prometheus almacena y consulta los datos y Grafana los visualiza de forma comprensible. Grafana, además, no está atada a Prometheus, ya que puede leer también de InfluxDB, de TimescaleDB y de muchas otras fuentes, por lo que es la capa de visualización estándar de facto para series temporales, sea cual sea la base que haya debajo. Para elegir entre las tres, una guía sencilla es que si ya se usa PostgreSQL y no se quiere aprender un mundo nuevo conviene TimescaleDB, que da series temporales manteniendo el SQL de siempre; si el caso son sensores o métricas y se quiere una herramienta dedicada conviene InfluxDB; y si lo que se busca es monitorizar infraestructura, el camino más transitado es Prometheus con Grafana.

**¿Cómo consiguen las series temporales comprimir tanto los datos?**
Las bases de datos de series temporales consiguen comprimir extraordinariamente los datos aprovechando una observación simple pero muy potente, que es que en una serie temporal los valores consecutivos se parecen muchísimo entre sí. Cuando un sensor mide una magnitud física con frecuencia, como un termómetro que toma la temperatura cada segundo, dos lecturas seguidas apenas cambian, por ejemplo veintitrés grados y cuatro décimas seguido de veintitrés grados y cuatro décimas otra vez, o de veintitrés grados y cinco décimas. Del mismo modo, el uso de procesador de un servidor de un instante al siguiente varía poco, y las marcas de tiempo avanzan en incrementos regulares y predecibles, por ejemplo exactamente un segundo cada vez. Cuando los datos son tan parecidos entre sí y tan regulares, se pueden comprimir de una forma que sería imposible con datos aleatorios. En lugar de guardar cada valor completo una y otra vez, la base de datos guarda solo las diferencias respecto al valor anterior, que son minúsculas y ocupan muy poco, y las marcas de tiempo, al ser regulares, se almacenan casi gratis, ya que basta con saber el intervalo y el punto de partida. En la práctica, esto significa que una base de datos de series temporales puede almacenar la misma cantidad de puntos ocupando una fracción del espacio que necesitaría una base relacional normal, que guardaría cada valor entero de forma independiente. Esta compresión tiene varias consecuencias beneficiosas encadenadas. Al ocupar mucho menos espacio, caben más datos en el mismo almacenamiento, lo que permite conservar históricos largos a bajo coste. Además, como las consultas tienen que leer físicamente menos datos del disco, resultan más rápidas. Y el coste de conservar el histórico se reduce notablemente. A esta compresión se le suman las otras optimizaciones de las bases de series temporales, como la escritura secuencial pensada para la avalancha de inserciones que llegan en orden temporal, y las funciones para agregar por ventanas de tiempo, que permiten calcular promedios por minuto o máximos por hora directamente en la base sin necesidad de traer millones de puntos crudos a la aplicación. La combinación de estas tres capacidades, la escritura masiva optimizada, la compresión agresiva y la agregación temporal nativa, es precisamente lo que separa a una base de datos de series temporales de una simple tabla relacional con una columna de fecha.

**¿Cuándo conviene usar una base de datos de series temporales y cuándo no?**
Conviene usar una base de datos de series temporales cuando se tienen datos que llegan con marca de tiempo en gran volumen, como métricas de sistemas, telemetría de sensores del internet de las cosas o datos financieros con muchas mediciones a lo largo del tiempo, y no conviene usarla para datos de negocio normales que se leen y modifican de muchas maneras, ni para datos que se editan con frecuencia, casos en los que sigue siendo correcta una base de datos relacional. Los casos en los que una base de series temporales encaja bien comparten el patrón característico de estos datos. El primero son las métricas de sistemas, como el uso de procesador, la memoria o las peticiones por segundo de servidores y aplicaciones, que se recogen sin parar y generan un flujo continuo de puntos. El segundo son los sensores del internet de las cosas y la telemetría en general, que producen datos con marca de tiempo en gran volumen de forma constante. El tercero son los datos financieros o de mercado, como precios y cotizaciones con muchas mediciones a lo largo del tiempo. En todos ellos, el volumen es alto, los datos no se modifican una vez registrados y se consultan por rangos de tiempo, que es justo el patrón para el que estas bases están optimizadas. Por el contrario, hay casos en los que no conviene usar una base de series temporales. Los datos de negocio normales, como los usuarios, los pedidos o las facturas de una aplicación, que se leen y se modifican de mil maneras distintas y se relacionan entre sí, se manejan mejor con una base de datos relacional, que está diseñada para ese tipo de uso. Tampoco conviene para datos que se editan con frecuencia, ya que las bases de series temporales parten del supuesto de que el pasado no cambia y no están pensadas para modificaciones constantes. Además, hay que tener cuidado de no adoptar una base de series temporales por si acaso, sin necesidad real, ya que si el volumen de datos es pequeño, una tabla relacional con un buen índice sobre la columna de fecha es más que suficiente y evita añadir una herramienta nueva. Por último, cuando sí se usa una base de series temporales, conviene recordar configurar la caducidad automática de los datos viejos si no hace falta conservar años de histórico en su forma cruda, para no acumular datos innecesarios. En resumen, la clave está en reconocer si los datos siguen el patrón de las series temporales y si su volumen lo justifica, usando la herramienta especializada solo cuando realmente aporta.

**¿Necesito aprender un lenguaje nuevo para usar series temporales?**
No necesariamente se necesita aprender un lenguaje nuevo para usar bases de datos de series temporales, ya que depende de la herramienta que se elija, y en particular existe la opción de TimescaleDB, que permite manejar series temporales usando el lenguaje SQL de siempre. La respuesta varía según la base de datos concreta. Algunas bases de series temporales dedicadas, como InfluxDB, tienen su propio lenguaje de consulta, distinto del SQL tradicional, de modo que usarlas implica aprender esa sintaxis específica, aunque a cambio ofrecen funciones muy adaptadas a las series temporales. Sin embargo, no todas las opciones exigen aprender algo nuevo. TimescaleDB es precisamente la alternativa pensada para quien no quiere cambiar de mundo, ya que no es una base de datos independiente sino una extensión de PostgreSQL, que es una base de datos relacional muy extendida. Al ser una extensión de PostgreSQL, TimescaleDB permite seguir usando el lenguaje SQL de toda la vida para consultar y manejar las series temporales, de modo que quien ya conoce SQL puede aprovechar ese conocimiento directamente, sin tener que aprender un lenguaje de consulta nuevo, y además puede seguir usando las mismas herramientas, controladores y bibliotecas del ecosistema de PostgreSQL que ya utilizaba. Esto hace que la barrera de entrada sea muy baja para quien ya trabaja con PostgreSQL, ya que las capacidades de series temporales se añaden encima de lo que ya sabe. Por otro lado, en el terreno de la monitorización de sistemas, Prometheus también tiene su propio lenguaje de consulta orientado a métricas, pero en muchos casos el usuario no escribe consultas a mano directamente, sino que interactúa con los datos a través de Grafana, la herramienta de visualización que dibuja las series en paneles con gráficos y tableros, lo que reduce la necesidad de dominar el lenguaje de consulta subyacente para las tareas más habituales de visualización y seguimiento. En resumen, si el hecho de aprender un lenguaje nuevo es una preocupación importante, la opción más cómoda es TimescaleDB, que da series temporales manteniendo el SQL de siempre, mientras que otras herramientas como InfluxDB o Prometheus tienen sus propios lenguajes, que aportan potencia específica a cambio de una curva de aprendizaje, en parte suavizada por herramientas de visualización como Grafana.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [Bases de datos](https://underc0de.org/foro/bases-de-datos/). Tipos de bases de datos y casos de uso.
2. **Underc0de, blog.** [Blog de Underc0de](https://blog.underc0de.org/). Monitorización e infraestructura.

### Documentación oficial

1. **InfluxData.** [InfluxDB Documentation](https://docs.influxdata.com/). Base de datos de series temporales.
2. **Timescale.** [TimescaleDB Documentation](https://docs.timescale.com/). Series temporales sobre PostgreSQL.
3. **Prometheus.** [Prometheus Overview](https://prometheus.io/docs/introduction/overview/). Monitorización y métricas.
4. **Grafana.** [Grafana Documentation](https://grafana.com/docs/grafana/latest/). Visualización de series temporales.

## Guías relacionadas

- [Relacional vs no relacional](../relacional-vs-no-relacional/index.md)
- [Bases de datos en memoria y Redis](../bases-de-datos-en-memoria-y-cache-con-redis/index.md)
- [Índices](../indices-en-bases-de-datos-como-aceleran-las-consultas/index.md)
- [Qué es una base de datos](../que-es-una-base-de-datos/index.md)
- [Índice de Bases de datos](../index.md)