đź’ˇ This test is performed on the Raid0 configuration and based on the formulas the IOPS and throughputs reduces 6 times on Raid6
To accurately benchmark database performance for large-scale IoT workloads, we simulated a scenario demanding approximately 170,000 data point changes per second—reflective of a typical industrial-scale environment. Using Kafka, identical message streams were fed simultaneously into MariaDB and TimeScaleDB, allowing for a direct comparison of their real-time ingest capabilities.
Once Kafka began generating messages, we immediately noticed increasing lag on the MariaDB side. MariaDB couldn’t ingest messages quickly enough, resulting in a steadily growing backlog. In contrast, TimeScaleDB kept pace easily, processing messages without noticeable lag. This aligns with our earlier benchmarks, where TimeScaleDB sustained a write throughput of approximately 1.4 million rows per second, compared to MariaDB’s limit of about 140,000 rows per second.
| Concurrency | Datapoints | Write Per Seconds Without Comparison | Write Per Seconds With Comparison | |
|---|---|---|---|---|
| MariaDB | 24 Partitions, 24 Consumers | 285.196.800 | 182.818 dp/s | 140.211 dp/s |
| PostgreSQL | 24 Partitions, 24 Consumers | 285.196.800 | 1.296.349 dp/s | - |
| TimescaleDB | 24 Partitions, 24 Consumers | 285.196.800 | 1.425.948 dp/s | 1.425.948 dp/s |
The graph below clearly shows how quickly TimeScaleDB ingests Kafka messages compared to MariaDB. While TimeScaleDB maintains a steady, rapid consumption rate, MariaDB experiences constant reads and steadily falls behind.
The partitioning strategy and indexing approach are identical on both MariaDB and TimeScaleDB, with each database configured to use 3-hour partitions. Both systems also utilize data compression and share the same composite index on the columns:created_dt,device_id, and metric_id.
The total uncompressed dataset over a two-day period was approximately 2 TB. After enabling compression, the data size decreased to 1.6 TB on MariaDB, whereas TimeScaleDB achieved significantly better compression, reducing the data to just 158 GB.
When evaluating read-query performance, we observed that MariaDB response times were notably slow—even when querying a single partition with an optimized index. In contrast, TimeScaleDB consistently returned query results within milliseconds.
We conducted tests using the following simple query, varying only the time range to measure performance:
| Time Period | MariaDB | TimeScaleDB | TimeScaleDB is Faster |
|---|---|---|---|
| 1 Minutes | 26021ms | 6ms | 4,337x |
| 2 Minutes | 28231ms | 59ms | 479x |
| 5 Minutes | 2640000ms | 182ms | 14,505x |
| 10 Minutes | - | 239ms | |
| 1 Hour | - | 511ms | |
| 5 Hours | - | 1099ms |
Analysis of the execution plans confirms that queries are effectively leveraging both partition pruning and the specified composite index.
We set up a Grafana dashboard to visualize data for specific devices and metrics. Queries executed against TimeScaleDB load promptly and reliably, whereas similar queries against MariaDB consistently fail or time out.
The query used to generate the Grafana visualization is as follows:
Our detailed benchmarking clearly demonstrates the substantial advantages of migrating to TimeScaleDB for large-scale, real-time IoT workloads compared to traditional solutions like MariaDB. Here are the key insights based on rigorous testing:
Superior Write Performance
Under identical conditions, TimeScaleDB achieved a throughput of 1.4 million rows per second, whereas MariaDB maxed out at approximately 140,000 rows per second. This difference makes TimeScaleDB roughly 10 times faster at ingesting data from Kafka streams.
Massive Compression Efficiency
TimeScaleDB significantly outperformed MariaDB in data compression. Over a 2-day period, TimeScaleDB compressed 2 TB of raw data down to only 158 GB, while MariaDB managed to compress the same dataset down to just 1.6 TB. This equates to about 10x better compression, directly translating into substantial storage cost savings.
Real-time Query Performance
TimeScaleDB consistently returned query results in milliseconds, even when querying across complex, indexed partitions. In stark contrast, MariaDB exhibited poor query performance, often resulting in severe delays or outright failures during real-time dashboard usage (e.g., Grafana visualizations).
Efficient Resource Usage
Both databases utilized identical partitioning strategies (3-hour partitions) and indexing schemes (created_dt,device_id, metric_id), underscoring that the performance advantages achieved by TimeScaleDB are fundamentally due to its optimized architecture for time-series data, rather than configuration differences.
Why This Matters for Your Business
Clients relying on MariaDB or other general-purpose databases for intensive IoT, real-time monitoring, or analytical workloads risk incurring excessive infrastructure costs, poor performance, and operational bottlenecks. Moving to TimeScaleDB delivers clear benefits:
Reduced infrastructure costs due to significantly better compression and efficient use of storage resources.
Real-time responsiveness, essential for competitive advantage in rapidly evolving industrial, IoT, or analytics environments.
Future-proof scalability, easily handling billions of rows without performance degradation or complex maintenance overhead.
Don’t remain limited by your current database’s constraints. Contact us today for a personalized assessment and start leveraging the full power and efficiency of TimeScaleDB.
Thank you for reading! If you're having problems with your database, don't hesitate to contact us.
Visit our contact page.
Hinterlasse einen Kommentar
Alle Kommentare werden vor der Veröffentlichung geprüft.
Diese Website ist durch hCaptcha geschützt und es gelten die allgemeinen Geschäftsbedingungen und Datenschutzbestimmungen von hCaptcha.