Message-ID: <67f791a3-4d49-425d-87b3-d6a0dbcda621@cloud.gatewaynet.com>
Date: Thu, 27 Feb 2025 09:19:53 +0200
MIME-Version: 1.0
Subject: Re: Ideas about presenting data coming from sensors
To: pgsql-general@lists.postgresql.org
References: <8d2dd92a-da16-435b-a38e-fe72191fc9d1@cloud.gatewaynet.com>
 <ea77fa23-6361-42f0-a511-8e0997dada26@aklaver.com>
 <d8892101-4cab-4f42-8c8b-9a84cb8ff767@cloud.gatewaynet.com>
 <f80fdc40-3179-4686-b8bf-4f45bb930b4d@gelassene-pferde.biz>
 <CAF3N6oR+8VvfrDEfp-VMD2FmTkPc4mLdqRixBgARCyuqjQHqpw@mail.gmail.com>
 <44a0b638-58f6-4a81-aadc-88aac3e2a842@cloud.gatewaynet.com>
 <a6d496e4-7f44-4bd9-86d9-d109df62a128@cloud.gatewaynet.com>
 <fb8407de-41dd-412c-aa79-ef10e7276517@aklaver.com>
 <823c2029-b225-4ea2-bf7b-d2a2fb2840ed@cloud.gatewaynet.com>
Content-Language: en-US
From: Achilleas Mantzios - cloud <a.mantzios@cloud.gatewaynet.com>
In-Reply-To: <823c2029-b225-4ea2-bf7b-d2a2fb2840ed@cloud.gatewaynet.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/67f791a3-4d49-425d-87b3-d6a0dbcda621%40cloud.gatewaynet.com>
Precedence: bulk


On 2/27/25 09:05, Achilleas Mantzios - cloud wrote:
>
> On 2/26/25 18:29, Adrian Klaver wrote:
>> On 2/26/25 01:27, Achilleas Mantzios - cloud wrote:
>>> Hi Again
>>>
>>> Up to this day we have set the data acquisition system running for 
>>> just one ship and writing the code to display the data. For less 
>>> than 20 days we have 6M rows.
>>>
>>> I gave a shot to timescale, installed locally as an extension, it 
>>> seems much prettier than having to do all the partition mgmt by hand 
>>> or other tools. However this seems more than a complete engine with 
>>> its own workers, so this seems like something new and big which 
>>> seems to me like something to commit to for a long time, something 
>>> to invest, on top of the already 25+ commitment we have with 
>>> PostgreSQL itself.
>>>
>>> So this is serious decision, so ppl please share your stories with 
>>> timescale .
>>>
>>
>> I don't use timescale, so this will not be about specifics. It seems 
>> to me you are well on the way to answering your own question with the 
>> choices you presented:
>>
>> a) '... it seems much prettier than having to do all the partition 
>> mgmt by hand or other tools.'
>>
>> b) 'However this seems more than a complete engine with its own
>> workers, ...'
>>
>> Either you do the work to build your own solution or you leverage off 
>> other folks work. The final answer to that comes down to what fits 
>> your situation. Which solution is easier to implement with the 
>> resources you have available. Either one is going to end up being a 
>> long term commitment.
>
> Thank you Adrian for all your companion and contribution in this thread!
>
> In haste I made some typos and maybe I was not well understood by 
> potential readers. I mean we are a traditional PostgreSQL house for 25 
> years. I started this DB from scratch, and now the whole topology of 
> postgresql servers (soon 200 in all 7 seas) has about than 60TB worth 
> of data. Since day one, I have been compiling from source, the base 
> postgres, the contrib, my own written functions, extra extensions. We 
> have never relied on a commercial offering, official package, or 
> docker image you name it. So now, it is the first time that I come 
> across a situation where the package / extension in question is big, 
> has somehow different doc style than the core postgres, I still cannot 
> navigate myself into it, plus the concern: I know PostgreSQL will be 
> here well after I retire, how about timescale? If they go out of 
> business or no longer support newer postgresql versions, what do we 
> do? Freeze the system for weeks, and move 100TB of data ? Employ some 
> logical replication from timescale to native postgres somehow 
> utilizing this new table "routing" rules that are available or will be 
> available by the time? Hire some known PostgreSQL support company to 
> do the job? Write my own data migration solution?
>
> That's why I am asking for user experiences on timescale.
Or Tempo pg-timeseries . Or any other alternatives. All those companies 
were at Pgconf2024.eu , unfortunately at the time, this project was 
still inactive , I wish I had contacted them all.
>
>>
>>
>
>