Timescaledb: Schema Design Considerations - Table per metric vs table with Type column

[Recodify]

Firstly, apologies if this is the wrong place to ask this question as it's not an issue but more a general question about performance of timescaledb and schema design.

Considering a system that has the following characteristics:

• Data points (metrics) are collected from many different systems at different times.
• Each of these metrics is generally one data point (e.g. temp and humidity are not reported at the same time, but rather individually and will have a different timestamp)
• The types of metrics that are collected will expand over time - the system is open and additional inputs will be supported over time (e.g. today we collect temp, humidity and cpu, tomorrow a sensor maybe added that monitors co2 and RAM).
• A summary of all metrics for a given time bucket needs to be obtained via a query and it likely to be the most common querying scenario.

The official docs cover 2 of the 3 ways I can think of modeling this.

1. Wide table - with table per category (covered)

Notes: has lots of sparse values due to the data points being collected individually. Storage of new metrics require a new column

2. Narrow table - with table per metric (covered)

Notes: Storage of new metrics require a new table

3. Typed table (not covered) - with single metric table (not covered)

Notes: Storage of new metrics just require a new row in the metricType table, no schema changes. Concerned about performance implications due to chunk size although grouping by a time bucket across all metrics would not require joins and could therefore be faster?

I was wondering if anyone could comment or the options presented, point me to some performance bench marks of timescale DB that include 3 as well as 1 and 2 or generally give any advice on the suitability of each approach. I'm planning to run my own experiments on this and I will post the results when done, but any insight at this stage would be gratefully received. :)

[Recodify]

I asked this same question on SO. One very comprehensive answer regarding relational dbs in general. https://stackoverflow.com/questions/54823674/relational-database-schema-design-for-metric-storage

Would still be excellent to get the thoughts of a timescaler on this. :)