Redis has transactions as well.

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)

Why isn't it intended use? And are there actual problems with it even if it isn't intended use?

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.