You can keep using redis and use FDW to access it as if it was a postgres table.
It does read and write to redis and can present redis data as regular tables to you.
I never really had to choose between redis and postgres. Postgres was always for safety and persistance and redis for sharing data and for providing realtime services with fast access to data.
I'm working on a project with multiple different data storage backends. I'd like to consolidate and use Postgres for more things. In one new situation we're starting to use Redis, thinking it will perform better than Postgres for a table that is updated a lot by concurrent background jobs.
I'm skeptical of no-sql stuff for various reasons. I'm wondering what PG experts think -- is there is a way to configure Postgres to handle a table differently, so that it could compete with Redis? Or are there some workloads where it is definitely better to use an alternative data store?
This table will have a few million rows, five small columns. Rows will be updated, read, or inserted 5-10 million times a day, by concurrent processes. It operates like a key-value store in that most selects will be getting one row, and maybe updating that row. Ideally these processes could work without stepping on each other's toes and competing for locks.
