TDengine TSDB Read Cache for Real-Time Queries

In IoT and Industrial IoT scenarios, real-time querying of massive time-series data is a core business requirement. Many architectures rely on external caches such as Redis to reduce disk I/O, which increases architectural complexity and operations overhead. TDengine TSDB includes a built-in read cache mechanism that automatically retains the most recently written data for each table, reducing real-time query latency by up to 8x, without requiring third-party caching components.

The core value of the read cache

Over 80% of query requests focus on data from the last few minutes or hours. TDengine maintains an in-memory cache inside each vnode, automatically retaining the most recent data blocks for every Subtable. Queries read from memory first and fall back to disk on a cache miss. Benchmark tests show that with the read cache enabled, query latency for the latest data drops from hundreds of milliseconds to tens of milliseconds, delivering up to an 8x performance improvement.

Three core values define this capability:

1. High query acceleration: the latest data stays in memory, eliminating disk access for many real-time queries.
2. Transparent automatic management: the cache operates inside the storage engine with no application-level configuration or intervention.
3. No separate cache service: no external caching layer, no extra hardware, no separate maintenance procedures.

How the read cache works

The cache focuses exclusively on the most recently written data. Each vnode automatically keeps the latest data blocks for every Subtable it manages, while older blocks are evicted automatically. Data is first written to the WAL for durability, then written to the in-memory cache, achieving a “visible immediately after write” property. The Query Engine automatically determines whether requested data resides in the cache. For queries that span both cached and disk-resident time ranges, the engine merges results from both sources transparently to the application layer.

Comparison with external caches such as Redis

The following table compares TDengine’s built-in read cache against external caching approaches across seven dimensions:

Dimension	TDengine built-in cache	External cache (Redis)
Deployment	Integrated, no extra components	Separate cluster required
Data consistency	Automatic; engine managed	Manual invalidation needed
Cache invalidation	Time-driven FIFO, automatic	Custom logic required
Operations cost	None beyond TDengine itself	Additional cluster to maintain
Development complexity	Zero application code	Cache logic in every service
Memory efficiency	Only latest blocks per table	Full data duplication
Data persistence	Shares WAL durability	Separate persistence config

TDengine’s built-in cache has clear advantages in operations cost, development complexity, and data consistency.

Applicable scenarios

Real-time monitoring dashboards. Dashboards that refresh at second or minute intervals benefit directly: every refresh reads the latest data from memory, improving response speed several times over.

IoT device status queries. Even when managing millions of devices, the latest status for any device returns in milliseconds because each Subtable’s most recent data sits in memory.

Industrial real-time alerting. High-frequency polling for the latest readings completes entirely in memory, substantially reducing resource consumption and response latency.

Configuration and tuning

Two primary parameters control the read cache:

• cache: sets the cache size per vnode (default 16 MB). Increase this value when memory is plentiful to hold more data blocks.
• cacheLastRow: controls whether the last row of each table is cached. Enable this when queries predominantly fetch the latest value for each device.

Tuning recommendations:

• When memory is abundant, increase the cache value to extend the time window of cached data.
• When queries focus on the most recent value per device, enable cacheLastRow for sub-millisecond LAST(*) response.
• When write volume is high but query frequency is low, the default settings are sufficient.

Performance comparison

The following results come from a benchmark with 10 million Subtables and 10 million writes per second:

Query scope	Without cache	With cache	Improvement
Latest single row	120 ms	15 ms	8x
Last 1 minute	350 ms	45 ms	7.8x
Last 10 minutes	580 ms	95 ms	6.1x
Last 1 hour	1,200 ms	420 ms	2.9x

The read cache delivers the strongest acceleration for the newest data, with the benefit tapering off as the queried time range extends further into the past.

Summary

TDengine integrates the read cache deeply into its storage engine, making cache management automatic and query acceleration transparent. An up to 8x query performance improvement is available without introducing external components such as Redis.