TimescaleDB 2.0 released, now distributed multi-node
Wow, this is a big deal. A free, distributed timescale database built on top of trusty Postgres, with column oriented, compressed storage for the time series data.<p>Also as I&#x27;ve stated before on HN, I love the new license which gives you almost all the freedoms of open source software while still letting TimescaleDB create a profitable business and not get squashed by AWS - which benefits nobody.<p>I have lot&#x27;s of questions:<p>Queries on distributed hypertables are run across the cluster, but what about regular queries to regular tables? Write transactions obviously need to happen in one server, but is there a way to split read queries across the cluster? I don&#x27;t know if regular table data is duplicated across data nodes, or if it&#x27;s only on the access node and joined transparently to the result set from the distributed hypertable query.<p>There are 3 kinds of server types for the cloud offering on AWS, IO, compute, or storage optimized. These seem to imply the database storage goes on instance storage, not EBS. This performs much better than EBS, especially on the high IO NVMe instances AWS offers. It also offers more predictable performance and tail latency because there is no network involved, no distributed block storage system (and EBS has had more than it&#x27;s fair share of outages.) Is this true? I know compose.io (IBM) does this for their managed PostgreSQL for similar reasons.<p>I&#x27;d like to compare the pricing to RDS for same-sized instances + storage, with moderate workload so I can get a feel for the markup on the managed service and know at at a glance, ok, this is going to cost me 50% more than RDS but I also get all these TimescaleDB features.<p>I&#x27;d also like to see some performance comparisons, just for regular read + write workloads on Postgres, because if I&#x27;m right about using instance storage vs EBS the same sized hardware will give more transactions per second for TimescaleDB.