I use Redis as the primary and only database. This results in quite large savings in terms of server infrastructure since memory has never been cheaper than it is today and the minimal amount of resources Redis consume in relation to the massive amount of throughput it provides.
Additionally, it has data persistence reliability on par with Postgres and other battle-tested databases[0], so couldn't be happier about that.
The selling point of Redis for me has been its simplicity. It has a fairly small set of features in comparison to other databases, yet extremely powerful.
"it has data persistence reliability on par with Postgres" if we pretend transactions do not exist and postgres is running in some non-default config then maybe, but we don't need to pretend.
yes and if you set
appendonly yes
appendfsync always
you will get about +/- PG write performance without all the features
Now I know 0 production projects using these Redis settings and I would argue it's not intended use of Redis same way as running PG with fsync = off is not generally what you want to use
My experience is actually that you'll often get a lot worse performance with redis if you enable durability. The reason being that postgres can batch several connection's/session's transaction commit fsyncs together, which IIRC redis can't.
(Disclaimer: Postgres guy, so I'm likely not impartial)
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.
> 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.
Have you even read the article? This was caused by Mongo running with a wrong flag, and the authors explicitly said that their backup script only contained ONE backup. That's bad engineering, not fault with Redis. Redis is extremely safe if you configure it correctly.
Yes, on a small number of nodes it works in a handful of use cases. That isn't the same as it being equal and equivalent in terms of reliability at scale.
They resorted to weird hack-y shit for something I use MySQL or Postgres for on a regular basis. So have most people who built stuff on Redis like this:
> I use Redis as the primary and only database.
> Additionally, it has data persistence reliability on par with Postgres and other battle-tested databases[0], so couldn't be happier about that.
redis by default does not fsync every change, instead it syncs every second. So no it's data reliability is not on par with Postgres in the default configuration.
The selling point of Redis for me has been its simplicity. It has a fairly small set of features in comparison to other databases, yet extremely powerful.
[0] - http://oldblog.antirez.com/post/redis-persistence-demystifie...