Why Postgres + Redis instead of just redis?


(Callan Bryant) #1

I know that an SQL database is pretty much the de facto for a forum system, but it seems Redis could cope with a forum system. Just out of curiosity, why is Postgres also used?

I am guessing it’s because of storage space. Redis stores everything in RAM, which could be limiting (how limiting?). Is this correct?


(Jeff Atwood) #2

Redis was never designed or intended as a method of persistent storage. It is a networked memory cache.


(Erhune) #3

Aside from the persistence reasons (since Discourse is not a banking system, I’m sure they could put up with a “good enough” persistant layer using only Redis), the full-text search of Postgres could not be replaced by Redis alone (and I’m not sure Redis+Solr would be fundamentally better than Redis+Postgres).

Just my 2 cents :slight_smile:


(Dan Neumann) #4

Redis is a key/value store.

Forums like Discourse involve textbook relational data. Users have many posts have many replies have many likes belong to one user. It’s pretty much the textbook use-case of the relational database.


(Sam Saffron) #5

Sure, but how can it be WEBSCALE

http://mongodb-is-web-scale.com/

More seriously, try writing something like this in redis / mongo etc:

SELECT  "topics".* FROM "topics" LEFT OUTER JOIN topic_users AS tu ON (topics.id = tu.topic_id AND tu.user_id = 1) WHERE "topics"."closed" = 'f' AND "topics"."archived" = 'f' AND "topics"."visible" = 't' AND ("topics"."deleted_at" IS NULL) AND (topics.archetype <> 'private_message') AND (topics.created_at >= '2013-09-03 04:29:27.178822') AND (tu.last_read_post_number IS NULL) AND (COALESCE(tu.notification_level, 2) >= 2) AND (topics.id NOT IN (9533,9586,8168,9585,5564,8013)) ORDER BY CASE WHEN topics.category_id = 7 THEN 0 ELSE 1 END, CASE
        WHEN topics.category_id IS NULL and (COALESCE(topics.pinned_at, '2010-01-01') > COALESCE(tu.cleared_pinned_at, '2010-01-01'))
          THEN '3000-01-01'
        ELSE topics.bumped_at
       END DESC LIMIT 5 

Practically impossible, you would need to walk huge amounts of data, moving to a nosql solution would require a complete rearchitecture for negative benefit.