Hi Pengcheng, I think you bring up an important point for users that are not deeply following the implementation details. When I first heard of the table introduction, I had many unanswered questions in my mind about the implications for the implementation: Does the table model still use TsFile? Does this instead mean new parallel components for storage and engine? Would that ballon runtime requirements for those of us interested in running a TS DB in-device? Would IoTDB no longer be characterised as a TS columnar DB but some kind of hybrid?
These and other questions were subsequently cleared up in our meeting, but I think it is important that the project finds a good way to communicate that the storage approach is the same. Even if it is to simply state that it is same physical storage (TsFile) as you have done. That simplifies the mental model for both users initially evaluating the project and existing 1.x users: 'OK, it's all TsFile columnar storage underneath I can concentrate on selecting the best model for my needs'. In terms of mode vs model, personally I would use model. Whilst it could be considered that you are 'switching mode' over the TsFile storage, I think the more important point is that you are modelling a logical domain in a specific schema structure in the IoTDB implementation. When I think of the COVESA automotive data modelling, the Vehicle Signal Specification (VSS) has a tree structure, and a user could take advantage of the IoTDB tree model if tree traversal was important to them. The newer Simplified Semantic Data Modeling (S2DM) is designed to allow freer relationships between vehicle and other models. Here the decomposed nature of the domains (seat, hvac, driver etc.) means the IoTDB table model might be a better fit. In either case, the mental and data models are all about modelling the logical concepts (VSS, S2DM/VDM) and their implementation (IoTDB table/tree). 'Mode' seems to neither carry the importance or convey the activity. Best wishes, Steve Lawrence Renesas Electronics COVESA Data Architecture & Infrastructure team lead > -----Original Message----- > From: Pengcheng Zheng <[email protected]> > Sent: 09 February 2026 09:13 > To: [email protected] > Subject: Re: [DISCUSS] Terminology choice: "Table Model" vs. "Table Mode" > (and Tree) > > Hi Yuan, > > Thanks for starting this thoughtful discussion — I find the distinction > very valuable. > > I’d like to add one perspective from an engineering and user-facing angle. > While I fully agree that Tree and Table represent two different logical > data models at the conceptual schema level, in IoTDB they are built on the > same physical storage (TsFile) and operate on the same underlying > time-series data. From a user’s point of view, this often feels less like > “choosing a model” and more like switching between two interoperable ways > of accessing and reasoning about the same data. > > One possible way to articulate this externally could be: “IoTDB provides > two logical data models — a Tree-oriented model and a Table-oriented model > — exposed to users as two interchangeable access modes over the same > underlying time-series data.” > > I’m curious how others see this trade-off between theoretical precision > and > user perception, especially in comparison with how “multi-model” is used > elsewhere. Looking forward to more thoughts. > > Best regards, > > Pengcheng > > Am Fr., 6. Feb. 2026 um 15:48 Uhr schrieb Yuan Tian > <[email protected] > >: > > > *Hi all,* > > > > I would like to initiate a discussion regarding the official English > > terminology for our dual-modeling capabilities in Apache IoTDB. > > Specifically, should we use *"Table Model"* and *"Tree Model"*, or > *"Table > > Mode"* and *"Tree Mode"*? > > > > After some consideration, I highly recommend adopting *"Table Model"* > > and *"Tree > > Model"*. Here is the reasoning based on classic database architecture: > > > > As we know, the standard *three-level schema architecture in database > > theory* consists of the External Schema (User Level), Conceptual Schema > > (Logical/Model Level), and Internal Schema (Physical Level). This > structure > > ensures data independence by isolating user views from physical storage. > > > > In the context of IoTDB: > > > > - > > > > *Unified Physical Layer:* Both "Tree" and "Table" share the same > > underlying physical storage format (TsFile). > > - > > > > *Conceptual Distinction:* The primary difference lies in the > *Conceptual > > Schema*—the way we model the data. Each modeling approach carries its > > own unique logic, constraints, and mappings. > > - > > > > *External Impact:* These different conceptual models further > determine > > their respective External Schemas and query syntaxes. > > > > If we were to use "Mode," it might imply a superficial switch in > "External > > Schema" or "syntax style." However, *"Model"* accurately reflects that > we > > are providing two different logical frameworks for data representation > on > > top of a unified storage engine. > > > > I would love to hear your thoughts on this. Do you agree with using > > "Model," or do you see any advantages to using "Mode"? > > > > *Best regards,* > > > > Yuan Tian > >
