TimescaleDB 2.7 vs. PostgreSQL 14
timescale.com
TimescaleDB 2.7 vs. PostgreSQL 14
1–10 of 56 posts
Re: TimescaleDB 2.7 vs. PostgreSQL 14
#2What about TimescaleDB vs a lot of other OLAP databases like ClickHouse, Druid, Pinot, Databend, etc.?
Or hybrid databases like StarRocks or TiDB?
Re: TimescaleDB 2.7 vs. PostgreSQL 14
#3Should be noted that article is titled Timescale + Postgres vs. Postgres alone. Timescale is built on Postgres so it's not really a competition per se.
Re: TimescaleDB 2.7 vs. PostgreSQL 14
#4Should be noted that article is titled Timescale + Postgres vs. Postgres alone. Timescale is built on Postgres so it's not really a competition per se.
Yes, I expected something like InfluxDB 2.0 vs. Postgres.
Re: TimescaleDB 2.7 vs. PostgreSQL 14
#5Whenever I see these posts from TimescaleDB, I always want to ask them how it compares in performance to alternative extensions that implement the same features, rather than just comparing TimescaleDB to vanilla PostgreSQL.
For example, they mention their automated data retention and how it's achieved with one SQL command, and how DELETEing records is a very costly operation, and how "even if you were using Postgres declarative partitioning you’d still need to automate the process yourself, wasting precious developer time, adding additional requirements, and implementing bespoke code that needs to be supported moving forward".
There's zero mention anywhere of pg_partman, which does all of these things for you equally as simply, and is a fully OSS free alternative [0].
I get that it's a PG extension that competes with their product. I know that TimescaleDB does a few other things that pg_partman does not. But I can't help but find its (seemingly) purposeful omission in these, otherwise very thorough blog posts, misleading.
[0] https://github.com/pgpartman/pg_partman/blob/master/doc/pg_p...
Re: TimescaleDB 2.7 vs. PostgreSQL 14
#6If integration with PostgreSQL is not a requirement, I would suggest looking at QuestDB[1] for the best performing open-source timeseries database currently on the market.
[1] https://questdb.io/blog/2021/07/05/comparing-questdb-timesca...
Re: TimescaleDB 2.7 vs. PostgreSQL 14
#7Whenever I see these posts from TimescaleDB, I always want to ask them how it compares in performance to alternative extensions that implement the same features, rather than just comparing TimescaleDB to vanilla PostgreSQL. For example, they mention their automated data retention and how it's achieved with one SQL command, and how DELETEing records is a very costly operation, and how "even if you were using Postgres…
Seconded. I understand that Timescale extends Postgres, but I'd still like to see performance comparisons relative to other time-series databases such as InfluxDB or even TiDB.
Shameless self-plug: we're also building database technology, but for embedding vectors (https://milvus.io) rather than time-series data - when doing query performance comparisons, we get several orders of magnitude of performance improvement over traditional databases. It's an unfair comparison, so we generally avoid it.
Re: TimescaleDB 2.7 vs. PostgreSQL 14
#8How is this on HN frontpage?
Re: TimescaleDB 2.7 vs. PostgreSQL 14
#9No mention of ha in the documentation.
I can’t understand whether HA would rely on the standard postgresql tooling or if you have to pay for some kind of enterprise license to get it.
Re: TimescaleDB 2.7 vs. PostgreSQL 14
#10Whenever I see these posts from TimescaleDB, I always want to ask them how it compares in performance to alternative extensions that implement the same features, rather than just comparing TimescaleDB to vanilla PostgreSQL. For example, they mention their automated data retention and how it's achieved with one SQL command, and how DELETEing records is a very costly operation, and how "even if you were using Postgres…
Same. I've been experimenting with the recently fully open sourced Citus 11 and it's pretty incredible. To the point that I have a hard time imagining NOT using it going forward.
Maybe I need to do my own comparison at some point.