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.
>
>>
>>
>
>