Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The issue with this general rule of thumb is that we can swap Postgres for many others, including non-relational, and it works.


My rule is "use a single database for as many of you persistence needs as possible". Often Postgres is a good choice for that database, but many other general purpose DBMSs will work just as well.

In my previous company we used MongoDB, for almost everything, including text logs, request logs, job-queues and small template files. We added S3 since storing terabytes of files in a database is expensive. Now, I wouldn't choose MongoDB for a new app, since the data model and query language suck, but it performed reasonably across many use-cases.

For my next application I will use Postgres as primary database. Probably will integrate S3 before going live, to avoid the necessary data migration later, but haven't decided yet if that's a premature optimization.


i don't think that's an issue. it's still a perfectly good rule.

use what you're familiar with, until it stops working. then use something else. postgres just goes a lot further than a lot of other tools before you get to the "use something else" phase. and postgres is the database a lot of people are familiar with.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: