Hi
in continuation of "Ideas about presenting data coming from sensors"

https://www.postgresql.org/message-id/flat/8d2dd92a-da16-435b-a38e-fe72191fc9d1%40cloud.gatewaynet.com

we got the system working in single tables fashion (3 kinds of them), since no timeseries solution seemed to fit 100% all the requirements at the time, or simply because I didn't have the time to evaluate all the existing options.

Fast forward today, in a few months we got almost 63M rows , but this will increase exponentially since new vessels will be configured to send their sensor's data.

After an initial idea with timescaledb, I tried to install pg_timeseries today, and give it a try.

pg_timeseries does not seem active and their "columnar" requirement seems to have stuck due to citus not having been updated to postgresql 17. Stopper.

timescaledb seemed mature, but also exotic, allow me the term. No way to use native logical replication, shortage of options to run on premise or self hosted, which leaves us with those options :

a) stick with timescaledb in their cloud offering and try to bridge the two systems (ours and the new timescaledb instance)

b) convert to native partitioning and just try to manage via partman, forgetting for the moment incremental views and columnar store, or maybe try to introduce some functionality from pg_ivm + pgcron

So the question : are those are our only options? google says so but is this really the case ?

thank you.




Reply via email to