Except for temporary tables which are wiped after each session.
Postgres has a shared memory cache, which can be set the same as redis, so your operations will all happen with in memory, with some background stuff putting it onto disk for you in the case your computer shuts off. Storage won't be involved.
BUT, postgres still has ~6x the latency [1], even when run from memory.
[1] https://medium.com/redis-with-raphael-de-lio/can-postgres-re....
If you have to parse and plan queries every time PostgreSQL is obviously much slower than Redis. It is much more interesting to see what happens if prepared statements are used.
And having a locking system fluctuate in latency between milliseconds and seconds would cause all sorts of headaches.
> 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.
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.
That's fine. If what you want is a single-node deployment combined with in-memory purism them SQLite has your back.
https://github.com/raphaeldelio/redis-postgres-cache-benchma...
A bit more work yes that could be simplified, but fully supported if you control the stack.
Highly recommended for running tests, especially in CI/CD pipelines. Doing this simple change can speed up DB-heavy tests 30-50%.
Is that relevant though? Some benchmarks on the web show Postgres outperforming Redis in reads as well as low-volume writes (less than 1k key-value pairs), and Redis only beating Postgres for high volume key-value writes.
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.