A time series database (TSDB) stores data points indexed by timestamp and optimizes both write throughput and range queries for sequential, time-ordered datasets. Traditional relational schemas can lose performance when sensor networks or monitoring systems push very high write rates, especially without time-based partitioning, batching, and suitable indexing. TSDBs are designed for this workload, although performance still depends on schema, cardinality, hardware, and configuration.
TSDB: Key takeaways
- A TSDB stores data points indexed by timestamp and optimizes write throughput and range queries for high-frequency sensor and monitoring data.
- TSDBs often use append-heavy write models with time-aligned chunks, helping keep write performance high for large ingest workloads while reducing, but not eliminating, index overhead.
- InfluxDB delivers purpose-built write performance for time series workloads with a native line protocol; TimescaleDB extends PostgreSQL for teams that need full SQL compatibility in a TSDB environment.
- Cedalo connects Eclipse Mosquitto natively with both InfluxDB and TimescaleDB, covering the full data path from MQTT transport to TSDB persistence and real-time monitoring.
How does a time series database differ from a relational database?
A relational database organizes data in rows and columns with flexible indexing and transactional logic. This model works well for operational data with complex relationships but becomes inefficient when write frequency exceeds what B-tree indexes can absorb cleanly.
When a sensor network writes a temperature reading every 100 milliseconds, a relational database accumulates index overhead with every insert. The cost of maintaining those indexes at high write rates creates a bottleneck that no query optimization resolves.
| Dimension | RDBMS | TSDB |
|---|---|---|
| Write model | Random inserts, index update per row | Append-only, sequential writes |
| Primary index | B-tree on arbitrary columns | Timestamp as native primary dimension |
| Schema | Fixed, normalized | Flexible tags + fields |
| Compression | General-purpose | Time-aware delta encoding |
| Retention | Manual | Automatic via retention policies |
| Best fit | Transactional data | High-frequency measurement data |
The core difference is not storage capacity but write architecture. TSDBs are optimized for append-heavy models where new measurements usually append to time-ordered storage. Index work is reduced compared with generic relational schemas, but indexed metadata and new series can still create overhead. This helps maintain high write throughput under suitable workload and infrastructure conditions.
How do TSDBs store and query time-stamped data?
Time series database architecture centers on a single principle: timestamp is the primary sort key for every data point. All storage, compression, and query logic derives from this ordering.
Data usually arrives roughly in chronological order and is written into time-aligned chunks, each covering a defined interval such as one hour or one day. Depending on the database and policies, older chunks may be compressed, retained, dropped, or moved to longer-term storage. This makes range queries faster because the database scans only chunks within the requested time window.
Write optimization in time series databases
TSDBs typically rely on append-heavy write models. New data points usually go to the current time-based chunk instead of arbitrary positions within a B-tree. This reduces the write amplification that generic relational schemas can generate when maintaining multiple indexes at high insert rates.
Most TSDBs buffer writes in memory using a Write-Ahead Log (WAL) or a comparable durability mechanism before flushing to disk in sequential batches. This approach delivers write throughput in the range of hundreds of thousands to millions of data points per second, depending on hardware, data model, cardinality, batching, and tuning.
Query performance for time-stamped data
Range queries are the natural query type for time series data. A request for all temperature values between 08:00 and 09:00 maps directly onto one or a few stored chunks, making the scan path predictable and short.
Aggregate functions such as avg(), max(), and sum() run on the storage layer, not in application code. The database applies these functions across time windows without loading raw data into memory first. Tag-based filtering further reduces the scan scope. Instead of joining multiple tables, a TSDB filters by indexed metadata attached to each measurement series.
What are the core features of a TSDB?
| Feature | Description | IIoT relevance |
|---|---|---|
| Retention policies | Automatic data expiry after a defined period | Manages sensor log volumes without manual cleanup |
| Downsampling | Aggregation of high-resolution data into coarser summaries | Preserves long-term trends without storage explosion |
| High write throughput | Millions of data points per second | Handles dense sensor networks reliably |
| Native time functions | Built-in range queries, window functions, rate calculations | Simplifies monitoring and alerting logic |
| Tag-based indexing | Metadata filtering without JOIN operations | Efficient querying across multi-device environments |
| Time-aware compression | Delta encoding and run-length compression | Reduces storage costs by 80 to 90% versus raw values |
Time series database examples: common TSDBs and their use cases
The TSDB market covers a range of purpose-built and hybrid solutions. InfluxDB and TimescaleDB are two of the most widely deployed options, each representing a distinct architectural philosophy with different strengths depending on team setup and workload type.
InfluxDB: purpose-built TSDB with native line protocol
InfluxDB uses a dedicated data model built around four components:
- Measurement: the logical table
- Tags: indexed metadata
- Fields: the actual values
- Timestamp
Data arrives via the line protocol, a compact text format that maps directly onto this structure:
temperature,location=plant1,sensor=s01 value=72.4 1700000000000000000InfluxDB query language and storage-engine support depend on the version. InfluxDB 1.x and 2.x support InfluxQL and, in 2.x, Flux for more complex transformations, while InfluxDB 3 supports SQL and InfluxQL. InfluxDB 1.x and 2.x use the TSM storage engine, while InfluxDB 3 uses a newer columnar architecture. Single-node write performance depends on hardware, data model, and cardinality.
Within a Cedalo MQTT architecture, Mosquitto broker metrics flow directly into InfluxDB via the InfluxDB metrics exporter. Metrics such as mosquitto_bytes_received, mosquitto_clients_online, and mosquitto_message_store_count become queryable time series within seconds of generation. The MQTT to InfluxDB integration guide covers the full configuration.
TimescaleDB: PostgreSQL-based TSDB for familiar SQL workflows
TimescaleDB extends PostgreSQL with a concept called hypertables, which are logical tables that partition data automatically into time-based chunks beneath the surface. From the application perspective, a hypertable behaves like a regular PostgreSQL table. Full SQL applies, including JOINs with relational tables.
This makes TimescaleDB the stronger choice when teams already operate PostgreSQL infrastructure and want time-series capabilities without migrating to a new query language. Continuous aggregates, a built-in TimescaleDB feature, precompute common aggregate queries in the background and serve results without scanning raw data at query time.
Cedalo’s Streamsheets environment connects to TimescaleDB via a native integration documented in the TimescaleDB connection guide. This connection lets teams feed processed MQTT data directly into a TimescaleDB hypertable for further analysis or visualization.
Where are time series databases used?
Time series databases cover a broad range of industries and technical domains wherever data arrives continuously and its value depends on when it was recorded. The four most common deployment contexts are infrastructure monitoring, industrial sensor pipelines, energy analytics, and application performance monitoring.
Infrastructure monitoring and alerting
Server and network monitoring generates high-frequency metrics covering CPU load, memory usage, request latency, and error rates at second or sub-second resolution. Prometheus scrapes these metrics and forwards them to a TSDB backend for long-term storage and alerting.
Within an MQTT-based architecture, broker metrics follow the same pattern. Mosquitto exposes a detailed set of operational metrics covering client sessions, message throughput, authentication results, and queue depths. The complete reference lives in the available metrics documentation. These metrics feed into InfluxDB or Prometheus, where alerting rules detect anomalies before they affect production operations.
Industrial IoT and sensor data pipelines
Factory sensors generate continuous data streams covering vibration, temperature, pressure, flow rate, and cycle counts. A single production line with 200 sensors reporting at 10 Hz produces 2,000 data points per second. Over eight hours, that totals roughly 57 million data points from one line alone.
MQTT handles transport between sensors and the backend. The broker receives published sensor data and routes it to a TSDB via a bridge or exporter. Once in the TSDB, teams run anomaly detection queries against historical baselines and build predictive maintenance models from time-windowed aggregates.
Energy monitoring and utility analytics
Smart grids and energy management systems track consumption, peak loads, grid frequency, and power factor at high resolution. Decisions about load balancing, demand response, and grid stability require sub-second data granularity across long periods of history. TSDBs store this data efficiently and maintain range-query performance over large historical windows through partitioning, retention, compression, and indexing strategies.
Application performance monitoring
APM tools track request rates, service latencies, and error distributions in real time. Grafana dashboards often query TSDB or observability backends to render live and historical panels side by side. Native aggregation functions calculate p95 or p99 latencies over sliding time windows at query time, without precomputed materialized views.
TSDB and MQTT: how time series databases fit into IIoT architectures
MQTT and TSDBs address two different problems in an IIoT data pipeline. MQTT moves data from devices to systems in real time. A TSDB stores that data persistently and makes it queryable over time. The two technologies form a natural pairing for industrial environments that require both low-latency transport and structured historical analysis.
The data path from sensor to dashboard follows four stages:
- Device layer: sensors and PLCs publish measurements to MQTT topics on a defined schedule or on value change.
- Broker layer: the Mosquitto broker receives published messages, applies access control, and routes them to configured destinations.
- Persistence layer: a bridge or exporter writes MQTT payloads into the TSDB using its native ingest protocol (InfluxDB line protocol or PostgreSQL COPY for TimescaleDB).
- Visualization layer: Grafana or a comparable tool queries the TSDB and renders time-series panels with aggregations, thresholds, and annotations.
MQTT’s decoupled publish-subscribe model keeps devices largely independent from the storage backend. Teams swap or extend TSDB backends without touching device firmware, though bridge or exporter configuration needs updating when the backend changes.
When does a TSDB make sense for your project?
| Scenario | TSDB | RDBMS |
|---|---|---|
| More than 10,000 data points/sec from sensors | Yes | Depends on schema, partitioning, indexing, and tuning |
| Complex transactional logic with rollbacks | No | Yes |
| Long-term metric retention with automatic downsampling | Yes | No |
| Mixed operational and analytical queries | TimescaleDB | Depends |
| Full-text search on log messages | Usually no | Possible, but dedicated log/search systems are often better |
| Grafana dashboards on time-based sensor metrics | Yes | Limited |
| Existing PostgreSQL team, no new query language | TimescaleDB | No migration needed |
Decision criteria for choosing a TSDB
Choose a TSDB when the primary data characteristic is high-frequency, ordered, time-stamped measurements where append-only write patterns dominate. The decisive factors are write rate, query type, and retention requirements.
A general-purpose RDBMS remains the right choice when data has complex relational dependencies, requires multi-table transactions, or arrives at low write frequency with flexible read patterns. TimescaleDB occupies a useful middle position, handling time-series workloads at scale while retaining full SQL compatibility for teams that need both capabilities.
From raw sensor data to actionable insights in practice
A TSDB solves a workload that traditional relational schemas were not primarily designed for. It can store large volumes of time-stamped measurements reliably, query them efficiently, and help keep storage costs under control as data volumes grow.
The combination of MQTT and a TSDB backend can cover the full data path from device to dashboard using native bridges, exporters, or connectors instead of building the entire integration layer from scratch.
Your advantages with Cedalo:
- Mosquitto broker metrics flow directly into InfluxDB or TimescaleDB via native integrations.
- Real-time broker monitoring through the Cedalo Management Center helps detect anomalies earlier, before they escalate into production impact.
- Clustering and high availability keep the MQTT transport feeding your TSDB online during individual node failures, given a correctly configured HA deployment.
- Open-source flexibility with enterprise-grade support, so your team can move fast while retaining access to reliability features and expert support.
One platform for MQTT transport, TSDB persistence, and monitoring
Connect your sensors, broker, and database in a single production-ready architecture with native InfluxDB and TimescaleDB integrations, clustering, and live monitoring.
TSDB: Frequently Asked Questions
What is the difference between a TSDB and a data warehouse?
A data warehouse stores structured, historical data optimized for complex analytical queries across large datasets, typically with batch ingestion. A TSDB stores continuously arriving, time-stamped data optimized for high-frequency writes and time-range queries, making it the better fit for real-time monitoring and sensor pipelines.
How high is the write throughput of a typical TSDB?
Modern TSDBs can handle hundreds of thousands to millions of data points per second, depending on hardware, batching, schema design, and cardinality. InfluxDB ingestion benchmarks vary by version, deployment model, and workload, so single-node throughput should be validated against the target use case instead of assumed as a fixed threshold.
What does cardinality mean in a time series database?
Cardinality refers to the number of unique tag value combinations across all measurement series in a TSDB. High cardinality, for example one unique tag per device across millions of devices, increases memory consumption and degrades query index performance significantly.
Does Cedalo support direct integration with InfluxDB and TimescaleDB?
Cedalo provides integrations for both InfluxDB and TimescaleDB. The InfluxDB bridge and related exporter components can export Mosquitto data or metrics into InfluxDB, while Cedalo also lists a TimescaleDB bridge for storing MQTT data in TimescaleDB.
Can a TSDB replace a message broker like MQTT?
No. A TSDB persists and queries time-stamped data, but it is not designed to replace real-time message routing, device-level MQTT sessions, or publish-subscribe communication. MQTT and a TSDB address different layers of an IIoT architecture and usually work together rather than replacing each other.
How does Cedalo connect MQTT data to a TSDB in practice?
The Mosquitto broker receives sensor data via MQTT and forwards it to a TSDB through a bridge, exporter, or connector. Cedalo’s Management Center monitors broker-side activity in real time, including metrics such as message throughput, client sessions, and authentication events.
When should teams use TimescaleDB instead of InfluxDB?
TimescaleDB is often the stronger choice when teams already run PostgreSQL and need SQL compatibility for joining time-series data with relational tables. InfluxDB can fit better for pure time-series workloads where teams prioritize purpose-built time-series ingestion and are comfortable with the query languages supported by their chosen InfluxDB version.
