[HN Gopher] Reliably Replicating Data Between PostgreSQL and Cli...
       ___________________________________________________________________
        
       Reliably Replicating Data Between PostgreSQL and ClickHouse
        
       Author : saisrirampur
       Score  : 23 points
       Date   : 2025-02-20 04:59 UTC (2 days ago)
        
 (HTM) web link (benjaminwootton.com)
 (TXT) w3m dump (benjaminwootton.com)
        
       | jascha_eng wrote:
       | Not to sound too sales-y but if you are looking into clickhouse
       | and are currently based on postgres, you might also want to check
       | out timescale. Since we're just a postgres extension it's 100%
       | compatible with existing systems but provides a lot of the same
       | speed benefits as clickhouse for analytical queries.
       | 
       | Don't be confused by the timeseries branding.
        
         | geoka9 wrote:
         | Could you go into the details of how one might go about
         | replicating a PG db to a tsdb one? I assume application level
         | would not be the most simple/reliable?
        
           | asadawadia wrote:
           | you don't
           | 
           | the data stays in PGDB - TSDB is an extension installed onto
           | the data base server
        
         | tomnipotent wrote:
         | Not at all too sales-y.
         | 
         | I'm all for keeping as much as possible in your initial
         | Postgres deployment as possible. If your team isn't having to
         | work around things and things "just work" it's a wonderful
         | conjunction of requirements and opportunity. It's incredible
         | how much you can get out of a single instance, really
         | remarkable. I'd also add it's still worth it even if there is a
         | little pain.
         | 
         | But I've found that once I cross about 8-12 terabytes of data I
         | need to specialize, and that a pure columnar solution like
         | ClickHouse really begins to shine even compared to hybrid
         | solutions given the amortized cost of most analytic workloads.
         | This difference quickly adds up and I think at that scale
         | really makes a difference to the developer experience that a
         | switch is worth the consideration. Otherwise stick to Postgres
         | and save your org some money and more importantly sanity.
         | 
         | You reach a point when you have enough queries doing enough
         | work that the extra I/O and memory required by PAX/hybrid
         | becomes noticeably more costly than pure columnar, at least for
         | the workloads that I have experience with.
         | 
         | ClickHouse is now in my toolbox right alongside Postgres with
         | things to deploy that I can trust to get the job done.
        
         | whitepoplar wrote:
         | How does Timescale compare to other extensions like Citus and
         | Hydra/DuckDB?
        
         | qeternity wrote:
         | We use TSDB and are pretty happy with it.
         | 
         | But it is _much_ less performant than CH.
        
         | simonw wrote:
         | I've been _very_ confused by the timeseries branding - I had
         | always thought timescale was purely about adding time series
         | features to PostgreSQL. I didn 't know the extension had other
         | applications.
         | 
         | Looks like you've expanded into vector indexing -
         | https://github.com/timescale/pgvectorscale - and an extension
         | which bakes RAG patterns (including running prompts from SQL
         | queries) into PostgreSQL: https://github.com/timescale/pgai
        
         | jascha_eng wrote:
         | I didn't expect so many comments. I'm about to fly cross
         | Atlantic and can't answer appropriately to everyone right now
         | without internet but will try to do it justice once I'm home.
        
       ___________________________________________________________________
       (page generated 2025-02-22 23:00 UTC)