Do you need Redis? PostgreSQL does queuing, locking, and pub/sub

Re:Do you need Redis? PostgreSQL does queuing, locking, and ... by sgarland on Sunday November 03, 2024 @07:06PM (#42037195)

If you are both small enough that you’re considering cohosting the app and DB, the odds are good that your working set is small enough to comfortably fit into RAM on any decently-sized instance.

> And having a locking system fluctuate in latency between milliseconds and seconds would cause all sorts of headaches.

With the frequency that a locking system is likely to be used, it’s highly unlikely that those pages would ever get purged from the buffer pool.

[ Parent | on HN ]

Re:Do you need Redis? PostgreSQL does queuing, locking, and ... by threeseed on Sunday November 03, 2024 @07:19PM (#42037257)

Once again. PostgresSQL does not have in-memory tables. So:

a) Writes will be happening on a slow, highly contentious disk.

b) You have no guarantees that the data will be in-memory.

Both of which make it a poor solution for use cases such as locking.

[ Parent | on HN ]

Re:Do you need Redis? PostgreSQL does queuing, locking, and ... by natmaka on Sunday November 03, 2024 @10:40PM (#42038226)

As pointed out by blackenedgem above: PostgreSQL has tablespaces, and one may simply declare tables which should stay in RAM in a tablespace built upon a tmpfs with enough reserved RAM to store them all. There is a only small associated burden (restoring the tablespace while starting PG).

[ Parent | on HN ]