Hacker News Reader

Comment by kristianp | Hacker News Reader

I like the openness here. It makes me nervous that the only db used is redis. I prefer a database that's backed by disk files, not one that's backed up occasionally. You get the performance of an in-memory database with redis though.

View on HN

Redis is my favorite database, and it’s interesting to me how many people are afraid of it losing data.

It’s easy to use both RDB and AOF persistence methods if you want a degree of data safety comparable to what PostgreSQL can provide you. See https://redis.io/topics/persistence

and it’s interesting to me how many people are afraid of it losing data.

Its more about data integrity.

Using a relational database with a well-defined schema gives you guarantees about integrity of your data that a key-value store like Redis would never be able to give.

The author specifically mentions DB choice: "redis can be replaced or complemented by another NoSQL database (such as MongoDB) or a relational database (such as Postgres). Throughout this section, where you see redis, feel free to replace it with the database you might want to use."

Redis persists to the filesystem pretty regularly by default, and can be configured to do it much more often. For example, the recommended configuration for its AOF persistence mode is to fsync every second, but you can set it to fsync after every command if you don't want to risk losing even a single second of commands.

Lots more info here: https://redis.io/topics/persistence

One second is a significant gap for data loss.

Also please be aware that if you use AOF persistence, and need to restore a redis instance from an AOF file, you MUST have at least the same amount of RAM available as the AOF file is in size or you cannot restore, and you can even corrupt the AOF in that instance.

I work somewhere that previously (before I started) decided to use redis as a database for many applications and it has caused a lot of pain and the engineering department severely regrets it. I do still recommend it as a great cache/session store, especially if you outsource it to elasticache.

> One second is a significant gap for data loss.

Definitely agree. I would not, for example, create a financial transaction system that is not backed by an ACID database that persists to disk.

If you have time/interest, I'd love to know more about the problems encountered by your team when using redis. In my experience, the main problem is scaling it to multiple instances (because RAM grows linearly with use). If the team also encountered other reliability issues, it would be valuable knowledge to me and perhaps others.

Odds are, with the amount of RAM available, you get the performance of an in-memory database with Postgres too.

Good point. I'm drawn to redis not so much for its performance (which can be comparable to that of a relational database) - but rather for the expressive power of storing data in general purpose data structures (hashes, lists, sets) rather than in relational databases. That expressive power is what I miss when not working with redis.

Can't you do all this with Postgres? I like Redis but as pg brings up its support for schemaless blobs or quisi-schemaless json blobs I find it harder and harder to find a solid use case for Redis.

Redis still has an edge on use cases with auto-expiration.

I've never really tried, but it looks like lists and hashes could be implemented in Postgres through json blobs. That would still leave out sets and zsets, which I also find essential in most work I do with Redis.

Besides having all the data structures, I love just connecting to Redis without specifying a database name (there's just a database number, which defaults to 0), a database user, or needing to create a table or a schema. Redis is, so to speak, just there. Not saying this is better than Postgres objectively - I just like it more.

Some of your patterns on the example application are super interesting - now I'm wishing for a redis-like, disk-first managed database and there isn't one. Its mostly document-stores out there.

Glad you find them interesting!

As for a redis-like disk-first database, it would be amazing, but I don't know if it is really possible (unless performance was severely sacrificed). This could be an interesting area to explore.

Reply on news.ycombinator.com