This simply isn't true. Redid can flush memory to disk and boot with that disk image. We use Redis and psql for persistent data stores without much issue. Writing to disk is an async process and typically doesn't disrupt performance unless it's a very large data set.
I mean, the thing is that postgre is storing this data to disk, and reading and writing to disk. In other words a Persistent Datastore. Meaning data will survive a reboot of the service.
Redis is a pure memory storage, it reads and writes nothing to disk. In other words it's a Volatile Datadstore. Meaning data will not survive a reboot of the service.
They serve two entirely different purposes. Redis is purely a cache server. So it stands to reason that of course it's going to be insanely fast at what it does.
But hey, want something even faster? Check out KeyDB. It's a fork of redis and I believe drop in compatible. But it uses Multithreading to do the work, where Redis stubbornly stays single thread.
Comment
This simply isn't true. Redid can flush memory to disk and boot with that disk image. We use Redis and psql for persistent data stores without much issue. Writing to disk is an async process and typically doesn't disrupt performance unless it's a very large data set.
Parent comment
I mean, the thing is that postgre is storing this data to disk, and reading and writing to disk. In other words a Persistent Datastore. Meaning data will survive a reboot of the service. Redis is a pure memory storage, it reads and writes nothing to disk. In other words it's a Volatile Datadstore. Meaning data will not survive a reboot of the service. They serve two entirely different purposes. Redis is purely a cache server. So it stands to reason that of course it's going to be insanely fast at what it does. But hey, want something even faster? Check out KeyDB. It's a fork of redis and I believe drop in compatible. But it uses Multithreading to do the work, where Redis stubbornly stays single thread.