The Redis AOF (commands flush to disk) and replication story is rock solid.
You can replicate writes to an offline secondary that even has scheduled RDB memory dumps or scheduled AOF rewrites.
We've never encountered data loss issues with our read and write heavy Redis services.
Curious... how does one confirm this? A lost acknowledged write is a very obscure thing and I don't think I would know if we lost writes.
Operationally, we sequence Redis downtime events. They're very rare. This is when most would be concerned about losing data.
We shift traffic to be hitless. Our model is eventually consistent across multiple regions. We won't accept writes in a cluster that is going down.
The Redis replication chain was chosen so that the primary Redis doesn't have to fork (aofrewrite, bgsave) or even do disk IO (AOF ops in general). We let our offline replicas do that work. The primary Redis can focus on serving reads and writes.
We alert on replication chain breakdown. We sequence traffic draining and primary / secondary swap operations for things like OS or Redis upgrades.
It's pretty sophisticated and largely automated.
This model tolerates losses of Redis instances. Only writes to the primary occurring in the short time before replication while not failed out might be lost. But that number would be incredibly, incredibly small. We would tolerate such losses.
We've got a lot of nines of reliability, and this pattern has scaled and served us well.
> We would tolerate such losses
In the context of the original concern, these are conflicting statements.
The underlying argument here is that you shouldn't use redis for anything you can't tolerate losing. Your use case and architecture is great and I'm glad it works well for you. But at the end of the day, there are workloads that can't tolerate such losses. And for those cases, redis is not a good fit.
If the design condition allows asynchronous operation and I don't need to wait for background tasks to finish before I reply, it's not faster unless I somehow care more about background CPU time per request than I do about things like storage guarantees.
If the design condition requires durable storage to have happened before I reply, putting it in Redis doesn't even count as getting started.
Edit: typos
I've certainly heard about MongoDB many, many times. I've heard of Redis some. I've heard of CouchDB. But this is the very first time I've ever heard of "Couchbase".
Compared to a closer example like RethinkDB, which was really cool, but nowhere near the money and marketing team ultimately failed. Rethink started in terms of stable data first, performance tuning from there... mongo went the opposite approach and caught up on the stability later. Of course scaling mongo and administration isn't as easy as a single node, or multiple read-replicas.
Because MongoDB is a single binary to download and install and has one of the simplest config files around.
It's arguably the easiest database to use and operate.
If you're looking for a super low-latency (everything sub-millisecond) document/json store with strong resiliency options, cross-data centre replication, options for optimistic/pessimistic locking, json sub document access and modification, etc etc, I don't know why you'd use anything else.
It really depends on your specific environment in terms of how much you are, or are not willing to lose information and it's all relative. I'm a fan of high performing databases (couchbase), or those more tunable (ScyllaDB/Cassandra), or build for indexing (elasticsearch), or those built for consistency (sql).
Each have their use cases, and there's definitely overlap. Understanding the difference and using the right tool for the job is important.
For a small project you might not want the added complexity of another database and decide to store JSON blobs in PostgreSQL. In this case it's important to understand the performance trade-off you're making.
A good description of redis is a "shared heap". HashSets, HashMaps, Heaps, Priority Queues, etc. are all great and fast in an application, but once you need to start sharing that data things get complicated quickly. So you designate a single server to implement those data structures and expose them to your application. And what you end up with is basically redis.
That's the difference between thinking about it as a solution to a problem and thinking about it as part of your infrastructure.
These days most databases are available as a managed service and Redis in particular is a standard feature on AWS, Azure and Google Cloud.
What about "redis-cli flushall"? (Don't type this on your production cluster).
ACLs in postgres are powerful and valuable and something that redis lacks.
Aside from lack of ACID you better hope your dataset never gets too large to fit in memory, tho.
You can configure postgres to behave more like Redis, and it will be faster if you do (at the cost of transactional guarantees).
A more interesting test might have been Postgres configured-like-redis vs Redis.
Its like saying that memcache is faster than postgres.
they do different things for different purposes.
I still wouldn't trust redis for anything other than ephemeral storage. Most of the use cases where we use redis assume that the data will at some point go away. The places where we use postgres assume that data is permanent.
Infact, we use both together, and it works really well, best of both worlds.