Hacker News Reader

Comment by lifeisstillgood | Hacker News Reader

This places the decision to move to Mongo or redis in serious doubt - it's an impressive competitive attack.

Mongo - Sure. I'm hardpressed to find genuine reasons to use MongoDB these days. Postgres provides everything I need in a persistent data store and has a ton of other stuff I didn't know I'd need (till you do!). Mongo was great to use with something like node.js where the async/schema-less model translates perfectly but using Postgres with the async driver[1] isn't bad either. Add in hstore, JSON support, plV8 ... and what exactly would somebody use Mongo for? :D

Redis - No clue what you're saying here. If you're using Redis then you're keeping your data in memory and dealing with low level structures. It's for completely different use cases. A classic example is rate limiting for an API. Doing it in Postgres with a disk I/O per request would cripple any semi-popular API. The data doesn't need to be exactly persistent (if we miss a few updates due to the server crashing we don't really care). In exchange for that it's blazing fast for individual writes that we can batch together to backup to something like Postgres (or Redis's built in persistence like AOF).

[1]: https://github.com/brianc/node-postgres

I'm in the middle of moving from mongo to postgres and I really couldn't be happier about it. During the migration I've found various bit of data that were corrupted over the life of the product (due to changes in the application). I already feel the relief of knowing what state my data is in. Oh, and I get to use sqlalchemy again which is a total win.

There is a Redis foreign data wrapper (https://github.com/pg-redis-fdw/redis_fdw) so you can access Redis from PostgreSQL. The new 9.3 adds writable FDW so you could even write to Redis from Postgres when the adapter supports it.

Redis is a good complement to Postgres. It provides caching and fast, non-persistent data store, while Postgres is the durable database.

Postgres has "unlogged tables" for the not-exactly-persistent use case.

Additionally (as unclogged tables will cause total data loss on failure as opposed to just missing some updates) you can alternatively tune, per transaction, the durability of your changes: PostgreSQL lets you tune the durability of individual transactions using the synchronous_commit variable, letting you go entirely asynchronous (where you toss data at the database, it returns immediately, and will be saved to disk during the next ganged commit).

Agreed - spoke too fast.

The new background workers in 9.3 enable Postgres to speak the MongoDB protocol.

See for example Mongres, https://github.com/umitanuki/mongres

I hope this allows frameworks like Meteor to trade up to Postgres.

The fact that PGSQL doesn't shit all over your data due to bugs (like Mongo) or lose it if you haven't checkpointed it to disk recently (like Redis) was a pretty big win for PG to start with...

Redis has AOF persistence that does not need any checkpointing to ensure your data will be there. PostgreSQL is awesome and I love it, but it has nothing to do with you not reading the Redis documentation :-)

\o/ for PostgreSQL, anyway.

Fair point. To be honest my redis knowledge is about a year old. The AOF however does have to be loaded on startup which is a big problem especially if it wasn't compacted.

Redis and postgres are very different tools serving different problem domains. If you're able to swap one out for the other, you might want to reëvaluate your architecture.

Not always. Both can be used as backends for persistent message queues since both have built-in pub/sub. If you do not have high throughput or latency requirements both are perfectly fine for this. If you already use PostgreSQL it is not always worth breaking out key value storage into Redis either.

Redis Pub/Sub is /not/ persistent. You can go the resque / sidekiq route and use a List and do blocking pops. But you have to make sure you have some persistence in place that you feel comfortable with (maybe a master / slave setup, with master handling all real queue load, and the slave doing AOF for recoverability).

Another diaeresis user! yay!

That's why I'm using both in my project :)

Check out antirez' great article about persistence[0] if you're interested in learning how to use redis in a more sophisticated manner than periodic checkpoints to disk.

0: http://oldblog.antirez.com/post/redis-persistence-demystifie...

We have a collection of semi-structured data that we've been storing with the JSON features in 9.3.

Very cool to build a full text search index based on things inside of JSON fields with about 10 minutes of time.

can you do a normal index on JSON though? I guess you can with the function based indexes. 9.3 actually makes JSON meaningful in Postgres since you can actually query it now. But there are no write operations, so MongoDB is still a ton nicer here with its atomic modifiers like $push.

> can you do a normal index on JSON though?

Yes, using the ->> operator you should be able to create an index on a JSON field, e.g.

   CREATE INDEX ON table ((field->>'thing'))

(an index on a JSON column makes no more sense than on e.g. an hstore column)

Indexing on JSON columns is key to storing semi-structured data with JSON. It's fairly useless without, for anything but small amounts of data.

I'm not sure what you mean, could you clarify/expand on your comment?

Reply on news.ycombinator.com