k-rus

Looking to the documentation it seems that a full export and import are needed. The docs still are focused on 12.

It is Apache version of TimescaleDB there (right?), which stays the same. While, those, who are using TimescaleDB under Timescale license, e.g., on premise, have now right to repair, for example.

Correct, the issue is due to confusing notices printed during pg_dump as it uses COPY TO underneath.

There are number of tools, which can be used in front of TimescaleDB or PostgreSQL. There are plugins for Telegraf, Kafka, Prometheus as described in https://docs.timescale.com/latest/using-timescaledb/ingestin...

Timescale builds connector and entire workflow to run Prometheus on top of TimescaleDB and support Grafana in flexible way: https://github.com/timescale/timescale-prometheus

This issue is related to slightly confusing _warnings_ that the software prints out, it doesn't effect the _correctness_ of the backups.

The warnings are produced by COPY TO, which is used by pg_dump, since COPY TO doesn't copy chunks. It is not an issue for pg_dump, since it also do COPY TO on each chunk table.

Timescale engineer here - was part of discussion about this warning. We need to do another round and see how to remove this confusion.

A TimescaleDB engineer here. Current implementation of database distribution in TimescaleDB is centralised where all traffics go through an access node, which distributes the load into data nodes. The implementation uses 2PC. Abilities of PostgreSQL to generate distributed query plans are utilised together with TimescaleDB optimisations. So PostgreSQL is used not just a dumb storage :)

I noticed that Zabbix supports PostgreSQL and TimescaleDB as back-ends and just checked the list, which contains also Oracle and SQLite (DB2 support is experimental).

You can use Prometheus on top of TimescaleDB. Timescale builds connector and entire workflow to run Prometheus on top of TimescaleDB and support Grafana in flexible way. Sorry for the promo :) check for details in https://github.com/timescale/timescale-prometheus

TimescaleDB provides such community features as compression, which allows to save space a lot, and continuous aggregates, which gives performance and save space if used together with retentions.

I believe TileDB had some customers when it was framed as the product. According to its website: "TileDB, Inc. is a data management company spun out of Intel Labs and MIT"

Link to wikipage with the exact game I mean: https://en.wikipedia.org/wiki/Pandemic_(board_game)

I can recommend Pandemic, especially, trendy nowadays :) It is not deduction, but more strategic. In this game you collaborate with the other player to win against the game, instead of playing against each other. If you play just two, every game you might need to modify you strategy, so it is different and is not boring :)

TimescaleDB uses heavily PostgreSQL API and hooks, which expose many data structures, macros and functions. My understanding is that using Rust or even C++ will require to write large FFI and also maintain it between PG major versions, which are released every year. Also, just having FFI is unlikely enough, and will require to write wrappers on top of it to use the best of Rust and not just another syntax on top of C.

I've heard several points for not choosing ClickHouse and going to TimescaleDB as an extension of PostgreSQL:

1. As it is already mentioned, if metadata (data about timeseries) are already in PostgreSQL, then it is nice to stay in the same database engine for querying data with joins of both metadata and timeseries data, so there is no need to implement integration of the two source in the application layer.

2. Also related to the first item: advantage of already knowing PostgreSQL API. ClickHouse has different management API, so it is necessary to learn. While if you know PostgreSQL, you don't need to learn new management API and only timeseries specific API of TimescaleDB.

3. ClickHouse doesn't support to update and delete of existing data in the same way as relation databases.

Then the final decision still depends on your need.

You can utilise multinode data replication for high availability of data, however it is still necessary to use an external tool for HA of the access node, which distributes data and queries to data nodes.