Ask HN: Is it feasible to use redis as the only datastore?

From the point of view of durability there are no problems in using Redis as a primary data store, make sure to use AOF with fsync everysec setting.<p>However if you should do it or not depends on the data you need to store, and even more in the kind of queries you want to run against the data set. If you end with a complex schema in order to support SQL-alike queries it is a bad idea. If you want to query data in a very Redis-API-obvious way, it is a good idea.<p>A few remarks about not correct ideas expressed in different posts here:<p>1) Redis transactions are not good since there is no rollback: not true since in Redis query errors can only happen in the case of a type mismatch more or less, so when you have a MULTI/EXEC block if there are no obvious bugs in your code you are going to see all the commands executed.<p>2) Redis durability is weak. Not true since with AOF + fsync it offers a level of durability that is comparable to many other data stores. Depends on the actual configuration used of course. Your usual MyISAM table for sure is not more durable than Redis AOF + fsync everysec just to make an example. Replication can add another level of durability of course.<p>3) RDB persistence instead <i>is</i> a weak durability configuration, but works for many applications where in the case of a bad event to have 15 minutes of data lost is a viable option.<p>So if you, for instance, are planning to use Redis to store your meta data, you can avoid having this same dataset duplicated in other places. Redis is also pretty solid in providing solutions to backup your data. For instance while you use AOF + fsync you can still call BGSAVE and create a compact .rdb file to backup. You'll always be able to restore the data set from the RDB file.<p>That said I think that in most complex applications using Redis + an on disk and "more query friendly" data store makes a lot of sense. Redis + Mongo, Redis + Mysql, Redis + Riak and so forth are very interesting configurations IMHO.

It depends on what your simple application does and what its needs are. I could rewrite either of my products to use Redis only, to the exclusion of SQL. It wouldn't be a very good use of my time, but it would be trivially possible. Neither of them put terrible stress on persistence engines. Heck, I could rewrite them to do everything in flat files and that wouldn't be impossible, either.<p>There are some rather relational-data-intensive projects I've been involved with where that would have been an Exceptionally Poor Idea, both for the amount of pain one would go through writing a poorly tested version of LEFT JOIN to be able to get it to work, and because one will eventually discover that your SQL database of choice has been improved for hundreds of man-years along axes you care about and Redis has not.

No. Redis is not a database, it's an in-memory key-value store. It's also called a [distributed] data structure server, which (at least to me) implies a tight coupling with your application: it's a way to offload shared state between multiple components, but the persistence of that shared state is not guaranteed.<p>In fact, Redis' persistence layer is best understood as a best-effort value-add. If the server shuts down for any reason, you have to simply hope the last disk flush was recent and successful. Otherwise, your data is lost. This is (again, to me) fundamentally at odds with the contracts that any database should provide. Also, Redis cluster is not yet released, which means running more than one Redis server requires you to manage keyspace sharding at the app layer.<p>Not that any of this is a knock against Redis. Even with those caveats, there are a huge class of problems that Redis is perfectly suited for. I love the software and use it daily. But Redis competes with memcached, <i>not</i> MongoDB; if you ever find yourself shoe-horning Redis into a role where total data loss is anything other than temporarily annoying, you're doing it wrong.<p>tl;dr: IMO, using Redis as a database is a really bad idea, for most common definitions of "database."

We're working on integrating Redis into our stack, but we use it mostly as a caching layer. As with any NoSQL datastore, your data will have to be structured far differently than if you were using a relational database. The nice thing about Redis is that it's a lot more effective than a simple key-value store for representing the data structures that exist in your application. If you're willing to put the time into learning this paradigm of data persistence the logical interaction with your data won't be a problem.<p>Redis does have a number of shortcomings. Firstly, it doesn't provide a very sophisticated transactions system. You get multi blocks, and the ability to watch keys (which is like a check and set), but you don't get true transactions. For example, there's no rollback mechanism, and commands will still be executed in a multi block if one of them fails.<p>Secondly, Redis by default does not provide strong guarantees of durability. It writes a snapshot to disk of your data periodically, so if something happens to the server that causes the program to shut down unexpectedly, you'll lose a lot of data. Redis can be configured to provide stronger guarantees of durability, but at the expense of speed.<p>Thirdly, there is currently no sharding mechanism built into Redis. They're working on Redis Cluster, which will allow your data to be spread across multiple servers, but it won't come out for sometime. You can build your own distribution system into your application however. You can read up on consistent hashing algorithms to help you with ideas for that.<p>Fourthly, everything is in memory at all times. That's pretty expensive, though Redis is quite efficient with memory usage.<p>Redis is really fast, which is awesome, but we still use MySQL as our primary datastore. We have a write-through/read-through caching layer, and if the transaction ever fails in part, we just rollback the MySQL transaction and invalidate the key in Redis, because we can trust that MySQL's records are more authoritative.

Yes, it is, but I think they serve different purposes. I'd use Redis for short-to-medium lifetime data that has high transaction rates. I'd use SQL for medium-to-long term data with lower transaction rates. We use both.<p>Redis does what it does well -- make great use of the CPU and the memory on a single box. SQL keeps your data consistent long-term and makes it easy to do ad-hoc queries.

If your data fits in memory and can be modeled on a key/value design, then why not?<p>A few things you might want to consider:<p>* depending on the size of your dataset, starting/rebooting redis can take a while. The bigger your dataset is, the longer it takes<p>* AOF can be a pain to maintain, since you need to allocate enough disk space for it + for when you back it up.<p>* if you plan to have millions of keys, compressing them isn’t a bad idea.

I was asking myself the same question and my answer was Draw![1]. I made this little app to learn more about Redis and html5 canvas element.<p>I wrote model/helper classes to wrap repetitive redis code, you can check the source at Draw! github repository[2].<p>Anyway after this experience I learnt Redis is a great tool but it doesn't fit good as a datastore for "everything" you should store for your app.<p>[1] <a href="http://drawbang.com" rel="nofollow">http://drawbang.com</a><p>[2] <a href="https://github.com/potomak/drawbang/tree/master/models" rel="nofollow">https://github.com/potomak/drawbang/tree/master/models</a>

With redis, all your data must fit in RAM on your server(s).<p>It really depends on how much data your application uses (and how much you expect it to use as you grow).

What do you mean by robust query capabilities? There are different types of values in redis, each with special operations, but you can't really query on the values. If you can model your data with hashes, simple values, and lists, then redis may suite you. I use it in conjunction with relational tools, but I can imagine using it solely for a simple project.

Redis operations are performed in RAM and while you can specify an interval where its contents should be written to disk you risk loosing some data if it closes unexpectedly. If that is not a problem I don't see why it couldnt be used as the sole datastorage.

Why not?<p>EDIT: If it meets your application's logical and scaling needs, there's no reason you couldn't use it