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.<p>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).<p>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 <i>can</i> override this in the config.. just be careful about that, because this lack of emphasis on security seems to run through it.)<p>Again, as a very fast and flexible cache that supports a million different datatypes and has real big-O performance guarantees, it is superb.<p>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.