3 ms·
Why isn't it intended use? And are there actual problems with it even if it isn't intended use?
by mbrock 10y ago
Why isn't it intended use? And are there actual problems with it even if it isn't intended use?
- jpgvm 10y agoIt'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.