3 ms·
It's not intended use because fsyncing every write to disk makes it inferior to every datastore designed to fsync every write. See here PostgreSQL. For read pe
by jpgvm 10y ago
It's not intended use because fsyncing every write to disk makes it inferior to every datastore designed to fsync every write. See here PostgreSQL.
For read performance if your dataset fits in memory PG is just as fast as Redis.
The main attraction of Redis is in-memory writes with async persistence. Trading durability and availability for the increased performance. If you give up this then there is precisely 0 reasons to choose Redis over PostgreSQL.
- anarazel 10y ago> The main attraction of Redis is in-memory writes with async persistence. FWIW, you can have that in postgres as well, cf. synchronous_commit = off > Trading durability and availability for the increased performance. If you give up this then there is precisely 0 reasons to choose Redis over PostgreSQL. As a PostgreSQL developer, I'd say that performance / latency / jitter can still be reasons to choose redis over postgres. The per-read overhead in redis is often a good bit lower than in postgres, and there's less variability in response times.