TimescaleDB does auto-sizing of the child tables (chunks) to keep write performance relatively constant while also making retention policy easy to do. That is, we make sure the chunks are aligned to time unit (e.g. an hour or a day) so when you want to remove data its dropping whole tables rather than individual rows.
Additionally, TimescaleDB comes with optimizations on the query side specifically for time-series data.
Yes we distribute the child tables among the cluster. Our default distribution mode uses "sticky" partitioning where a partition prefers to stay on the same node. This allows you to control data colocation via the partition key. Our clustered solution is not released yet but we plan to handle node failures via regular postgres STONIH mechanisms. Once node failure is detected, the system reconfigure which children to use.
Query parallelization works in single and multi-node cases.
And a clarification just in case this wasn't clear: We use constraint exclusion analysis to determine which of the "child tables" of the parent hypertable to query. So, when performing query parallelization, you aren't sending subqueries to chunks/nodes that will not match your SQL predicate (plus a bunch of other query optimizations we do with pushdown, etc.).
This is also true at write time: You can insert a batch of rows in a single insert, then the query planner will split them into sub-batches, which it then will insert into the appropriate chunk. So, you don't need to "pre-partition" your data before writing to the system (even in the forthcoming distributed version).
Additionally, TimescaleDB comes with optimizations on the query side specifically for time-series data.