If you have a datacenter of your own and several VMs, redis would be fine as a persistent store. I wouldn't do it but it would be fine.
If you are in the cloud and have any hint of using kubernetes then DO NOT USE redis as a persistent store. The problem is that redis' master/slave and replication pattern goes against the load balancing and Service objects of kubernetes. Redis was created in a time when it expected physical nodes to be available 24/7 and is not designed for nodes to go away. It can handle it but it isn't designed for it. Two different things.
Redis as a single pod and a cache works great. I would never use redis as a DB. We have DBs specifically designed to be DBs.
You can use an append only text file as a database, but that doesn’t mean it’s a great idea.
My understanding is that Redis is fast because it writes and reads from memory. Postgres is slower because it ensures writes are persisted to disk before responding (among other reasons). So even if you use RDB and AOF with Redis, you can still readily lose data even after the database has confirmed it's been written. The database can confirm a write and then crash before that write has been persisted to the AOF and RDB.
This is why I thought you wouldn't want to run Redis as a primary database.
In production, it may come back and haunt you later. There is very little in the way of real backup and recovery; you should think of the RDB and AOF files as a faster way to pre-populate the cache upon startup/reboot/migration rather than as a real production database. I've seen it used as a prod db many times, and while it can be made to work, it's not really what it's designed for.
The impedance match between redis and most programming language data structures is just really perfect; Redis supports all of the structures (arrays, maps, etc) that you'd expect, and a few you wouldn't (bloom filters, for example).
Also, it has some really odd security choices and just generally a lack of focus on security at all. It didn't even have any password at all for the first few years -- anyone could connect to it and just do whatever they wanted (and, in fact, you could even gain access to the OS!) It's also pretty hard to start up securely in the cloud (by default, it binds to every interface instead of just localhost, or at least the last time I checked, although you can override this in the config.. just be careful about that, because this lack of emphasis on security seems to run through it.)
Again, as a very fast and flexible cache that supports a million different datatypes and has real big-O performance guarantees, it is superb.
But these days, if you want a primary production database, you should just default to postgresql, unless you already have a solid reason to choose something else. If you don't know SQL, you should learn, but until you're really ready to, just use an object relational mapper (ORM) for your programming language and that will turn postgresql basically into MongoDB or similar, but with all the power of SQL behind it.
TLDW. But I have counter.dev running with redis as the primary database. It just works. Of course you need consider carefully. One of the advantages I saw is that every query on the database has a documented complexity. I don't need to hope for the database to run the query fast enough. It's more transparent.
You could also just use postgresql as your key-value store, which seems a much saner approach.
Why would you want to?
I remember when I thought it was a great idea to use Elasticsearch as a primary database. The decision was a mistake
I've been thinking about replacing my Mongo database with persistent Redis but I'm torn on this, I don't know what to expected long-term, what about migrations? It feels like once I'm going for a structure it'll be very difficult to alter it, but maybe I'm wrong. I'm developing a real-time application (think Figma), and still cannot choose a solution with confidence.
This was the case at ZEIT (now Vercel). Then we migrated away from that due to a slew of issues I can't recall at the moment.
We still used redis extensively but not as a persistence layer.
"Can Redis be used as a primary database"
IMHO, no. Unless! you can ensure your data is less than the size of memory. Redis must fit all the data into memory. If you run out of memory Redis doesn't have great options (besides buy more memory). In my mind a primary database handles the complexities/speed of pulling data from a disk, manipulating data in memory and scales with more disk. Redis manipulates data in memory only.
Redis is rad for specific group of problems.
Yes. Should you?
It depends, like everything.
At my company the decision to do this was taken a few years ago. It’s one we regret every day and are expending a large amount of effort digging ourselves out of it.
A query engine is a very powerful and useful layer of abstraction that you end up having to recreate in your application code for every scenario where you need some data. It’s complicated, it’s hard to get right and it really slows you down.
My recommendation would be: don’t do it.