[HN Gopher] Do you need Redis? PostgreSQL does queuing, locking,...
       ___________________________________________________________________
        
       Do you need Redis? PostgreSQL does queuing, locking, and pub/sub
        
       Author : fanf2
       Score  : 31 points
       Date   : 2024-11-03 21:42 UTC (1 hours ago)
        
 (HTM) web link (spin.atomicobject.com)
 (TXT) w3m dump (spin.atomicobject.com)
        
       | pjs_ wrote:
       | Because everyone insists on insanely distributed architectures,
       | most people will never really see the point of Redis, which is
       | that if it is running on the same machine as the application, it
       | can respond in much less than a millisecond. That lets you do
       | stuff in the application that you just can't do with Postgres.
       | Postgres kicks ass obviously but it is not running in memory on
       | the same machine as the application.
       | 
       | If all you want to do is queues and whatnot, then sure, you don't
       | need an in-memory KV store.
       | 
       | The point of an in-memory KV store is to do stuff _that needs the
       | performance characteristics of RAM_. You obviously can 't get the
       | performance characteristics of RAM over a network connection.
       | This is like, a tautology.
        
         | Eikon wrote:
         | [delayed]
        
         | nomel wrote:
         | > but it is not running in memory on the same machine as the
         | application.
         | 
         | What's the overhead of postgres vs redis, when run locally? Why
         | do you think postgres _isn 't_ run locally?
         | 
         | There's nothing special about postgres. It's just a program
         | that runs in another process, just like redis. For local
         | connections, it uses fast pipes, to reduce latency, and you get
         | access to some faster data bulk transfer methods. I've used it
         | in this way on many occasions.
        
         | hkon wrote:
         | But then you can have it in memory in your app.
        
       | Svoka wrote:
       | Consider using SQLite on NAS id you don't care about performance
       | to this extent.
        
       | threeseed wrote:
       | Pretty pointless article without doing performance benchmarks.
       | 
       | The entire point of Redis that it trades durability and
       | convenience for performance.
        
       | halfcat wrote:
       | The queue approach of `SELECT...FOR UPDATE SKIP LOCKED` is great
       | for low throughput needs. One thing to note: as your throughput
       | increases you will have to deal with bloat.
       | 
       | When the processed message rows are deleted, the pages sitting on
       | the disk are not deleted until vacuum is run. If you run an
       | online vacuum it doesn't delete the page from disk, and a full
       | vacuum (that will free up the disk space) locks the database
       | while it completes the vacuum (which if you're now dealing with
       | high throughput, is not great).
       | 
       | One approach to address bloat without dealing with vacuum is to
       | setup a timestamp-based partition on your queue table. This way
       | you just drop old partitions and it frees the disk space without
       | needing vacuum.
        
       | mannyv wrote:
       | Lets see pgsql deal with 15000 client connections.
        
       ___________________________________________________________________
       (page generated 2024-11-03 23:00 UTC)