tsbs

Disclosure: I work at AWS but not on Timestream. Opinions my own. Unless I'm missing something this is not an apples to apples benchmark. TimescaleDB is running as a single node without any replication whereas Amazon Timestream is replicated[0] to three AWS Availability Zones for durability. I've only skimmed the TSBS[1] repo and the start/stop scripts for TimescaleDB. Can someone confirm this? 0 - https://aws.amazon.com/blogs/aws/store-and-access-time-serie... 1 - https://github.com/timescale/tsbs

(Disclaimer: post author and Timescale employee) I'm sorry you feel like we were trying to be dishonest in the post. On the contrary, we put a lot of effort (and 7,000+ words) into trying to explain everything that we did - just as we've done with other benchmarks which others have linked to. The TimescaleDB test did not use continuous aggregates for these test, only raw time-series data stored in hypertables. For each database, we (and other contributors) do our best to use features in all cases that take advantage of the DB. For TimescaleDB, a function like LAST() happens to be really powerful for most workloads and is really, really fast. That's not cheating, it's using the software properly! :-) The SQL that we generate for each database can be examined here (https://github.com/timescale/tsbs/tree/master/cmd/tsbs_gener...) and as an o

Pre-reading hypothesis: TimescaleDB is declared orders of magnitude faster because the benchmark is serving results they're computing at writing time? Is it just like the ClickHouse benchmark from earlier, where they read from a `CREATE TABLE [...] ENGINE = AggregatingMergeTree`? Post-reading: "faster queries via continuous aggregates". So is this it? I couldn't find how tables / materialized views were created in the source though [1]. TimescaleDB is probably a very good product (and pg-compatible!), but producing such articles hiding the usage of a magic feature is sort of dishonest. Why not make an article directly on the power of the feature? It's hurting their brand reputation a bit. [1] https://github.com/timescale/tsbs

This is on the roadmap, we will work on integrating with https://github.com/timescale/tsbs, TSBS has Victoria Metrics support too.

Perhaps the QuestDB team could add it to the Time Series Benchmarking Suite [1]? It currently supports benchmarking 9 databases including TimescaleDB and InfluxDB. [1] https://github.com/timescale/tsbs

You can look at what we use in our benchmarking tool https://github.com/timescale/tsbs (results described here https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-...). Pretty much it's a table with time, value, tags_id. Where the tags table is id, jsonb

That's a good question! Especially considering these overwhelming benchmarks [1] made via Timescale TSBS [2]. [1] https://www.altinity.com/blog/clickhouse-for-time-series [2] https://github.com/timescale/tsbs