public inbox for [email protected]
help / color / mirror / Atom feedFrom: Achilleas Mantzios - cloud <[email protected]>
To: Adrian Klaver <[email protected]>
To: [email protected]
Subject: Re: Ideas about presenting data coming from sensors
Date: Thu, 27 Feb 2025 09:05:46 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAF3N6oR+8VvfrDEfp-VMD2FmTkPc4mLdqRixBgARCyuqjQHqpw@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
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.
>
>
view thread (11+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Ideas about presenting data coming from sensors
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox