Making “One Table per Device” a Reality with the Virtual Table

Jeff Tao

May 19, 2025 /

In the world of time-series data, structure matters. Whether you’re building a data pipeline for an industrial IoT deployment or designing a monitoring system for wind turbines, how you organize your tables can determine everything from query performance to engineering effort. And in these environments, sensors are many, data is fast, and the complexity never stops growing.

Traditionally, TDengine users have benefited from a powerful data modeling paradigm: one table per data collection point, organized into supertables. This approach enables efficient data storage, high-speed ingestion, and flexible querying across millions of devices. But as deployments scale, another need starts to emerge: one table per device.

The Challenge with One Table per Device

The idea of organizing all of a device’s data into a single table is compelling. From a business and analytics perspective, it feels natural: show me all the data for wind turbine #108 or pump station A12. But the technical reality is more complicated.

A single device typically includes multiple sensors, each with different collection intervals and data types — mechanical, electrical, environmental, and so on. Modeling all of that in one physical table would either require:

  • Sacrificing normalization and flexibility
  • Introducing large amounts of NULLs in each row (since not all sensors collect data at every timestamp)
  • Or performing complex multi-table joins that degrade query performance and increase maintenance overhead

This disconnect between data collection architecture and business logic is where virtual tables come in.

Enter the Virtual Table

To bridge the gap between physical schema design and real-world analytics needs, TDengine has introduced the virtual table: a flexible, query-time abstraction that lets users define custom logical views over existing tables, without duplicating data or changing their storage schema.

A virtual table is not a physical container and does not store data itself. Instead, it provides a dynamically generated view that merges selected columns from multiple subtables. This lets users analyze data as if it were in a unified table, while keeping the underlying structure optimized for write performance and storage efficiency.

With virtual tables, TDengine offers a middle ground: performance at scale, and simplicity at the query layer.

How It Works

You create a virtual table or supertable by selecting specific columns from multiple source tables. When you query the virtual table, the data in these columns are aligned by timestamp, with NULL filled in for any missing entries. And whenever new or updated data is written to the source tables, these changes are automatically reflected in the virtual table.

For example, if you have separate tables for wind speed, rotor torque, and temperature on a turbine, a virtual table can merge these into one unified schema aligned by timestamp, presenting a coherent time-series dataset that can be queried directly.

This is especially useful when:

  • Performing cross-sensor correlation analysis
  • Feeding unified datasets into visualization or ML pipelines
  • Simplifying user access to device-level data

Advantages of Virtual Tables

  1. Personalized Schema Without Redesign: With VTables, every team can define the schema they need without impacting the physical table design. Want to see only the environmental parameters? Create a virtual table with just those columns. Want to analyze everything together? Define a virtual supertable that spans them all.
  2. Real-Time, Query-Time Generation: Since virtual tables are generated at query time, they always reflect the latest data in the source tables. There’s no ETL or materialization step required. The data is where it has always been, just presented in a way that makes sense for analysis.
  3. Minimal Performance Trade-Off: Because the virtual table includes only the columns referenced in the query, it avoids the inefficiencies of pre-joining all possible fields. TDengine’s engine dynamically builds the necessary structure during execution, optimizing for speed and resource usage.
  4. Simplified Application Logic: Instead of juggling multiple queries or application-side merges, developers can treat virtual tables like any other table in TDengine. This reduces code complexity, improves readability, and accelerates time to value.

One Table per Device — Now Practical

For years, the supertable model has powered efficient data ingestion and retrieval in TDengine. But as real-world use cases evolved, so did the need to make data easier to consume. Virtual tables are a response to that evolution, allowing users to customize their view of the data without sacrificing the performance and scalability for which TDengine is known.

With this innovation, the long-standing vision of “one table per device” becomes not just a concept, but a practical, high-performance reality.

Ready to try it?

Virtual tables are available now in all versions of TDengine and are already helping companies like Extracellular streamline operations. Get started with the documentation and explore on your own or contact our solutions team to see how virtual tables can help you build a better industrial data architecture.

  • Jeff Tao

    With over three decades of hands-on experience in software development, Jeff has had the privilege of spearheading numerous ventures and initiatives in the tech realm. His passion for open source, technology, and innovation has been the driving force behind his journey.

    As one of the core developers of TDengine, he is deeply committed to pushing the boundaries of time series data platforms. His mission is crystal clear: to architect a high performance, scalable solution in this space and make it accessible, valuable and affordable for everyone, from individual developers and startups to industry giants.