Thanks for the comments, and it sounds like you want a deeper dive as to some of the design decisions around TimescaleDB.

What might be useful to start is two of our technical blog posts around how we design internal partitioning [1], as well as how this compares against declarative partitioning in PG10 [2].

We aren't rewriting the lowest storage layers like cstore_fdw, so we can continue to use Postgres' heavily-tested storage layers....as well as work with its existing streaming replication and recovery mechanisms. We also aren't packing individual writes into files (like it sounds you are doing with floatfile), arrays (like in tgres), or other TOASTED data structures, although we might be compatible. We certainly do support the range of types (arrays, JSON/B, etc.) in our data rows.

Fully agree that projects differ on their needs of inserts vs. queries time, but in addition to much higher insert rates, our general data model and aggressive constraint exclusion across chunks provides meaningful time-based query improvements. We also have all sorts of planner optimizations, e.g., we taught the planner that querying for the data by time rounded-to-some-time-bucket preserves the sort on time --- which is useful for all kinds of ORDER BY/GROUP BY queries. We've published various benchmarks around this [3].

Finally, there are a lot of changes needed to "just make things work", which also includes support for constraints, foreign keys, upserts, triggers, etc., which enable capabilities like data retention and continuous aggregation policies.

[1] https://blog.timescale.com/time-series-data-why-and-how-to-u...

[2] https://blog.timescale.com/time-series-data-postgresql-10-vs...

[3] https://blog.timescale.com/timescaledb-vs-6a696248104e