You are correct however that TimescaleDB requires more storage than some of these other options. If storage is the most important criteria for you (ie more important than usability or performance), then again I would recommend you to one of the other databases that are more optimized for compression. However, you can get 6-8x compression by running TimescaleDB on ZFS today, and we are also currently working on additional techniques for achieving higher compression rates.
This is a weird answer since compression is used by columnar databases like MemSQL and Clickhouse to both save on storage and accelerate queries. Compare this to using a generic a filesystem compression which would both compress worse and make the system slower.
We haven't really found it to be the case that the system is slower with ZFS. As the sibling mentions, you are trading some CPU for better I/O. We usually see better insert performance and similar/better query latency.
Compression may or may not be worse with ZFS defaults, but performance will almost certainly be _better_ with the default ZFS compression settings than an uncompressed filesystem. You're trading a small amount of CPU for IO, and that's usually a really good trade.
Comments
This is a weird answer since compression is used by columnar databases like MemSQL and Clickhouse to both save on storage and accelerate queries. Compare this to using a generic a filesystem compression which would both compress worse and make the system slower.
We haven't really found it to be the case that the system is slower with ZFS. As the sibling mentions, you are trading some CPU for better I/O. We usually see better insert performance and similar/better query latency.
Compression may or may not be worse with ZFS defaults, but performance will almost certainly be _better_ with the default ZFS compression settings than an uncompressed filesystem. You're trading a small amount of CPU for IO, and that's usually a really good trade.