3 ms·

Thanks for the feedback. So they're basically comparable, with a slight edge for MySQL. Guess I will play with both and pick whichever feels more handy. I have

Thanks for the feedback. So they're basically comparable, with a slight edge for MySQL. Guess I will play with both and pick whichever feels more handy. I have seen many discussions on Postgres and MySQL on hacker news, so I thought I might ask. What's the argument against asking such questions? Sorry, I only just signed up, after being a passive follower for a very long time.

trcollinson 11y ago
Oh no! The question isn't bad at all and this is the place to ask it! I don't mean to discourage you from asking on HN. What I mean by not asking those questions is when I am picking a system I usually ask other questions. Like: how much data am I going to be storing? What will he the structure of the data? Will I be heavy read, heavy write, or a mix of both? Will the data be pulled on a geographic or a time based system? Things like that. My requirements rarely worry about popularity. Also, again anecdotally, while it may seem like I endorse mysql, I actually prefer postgres. However, I am a big fan of meteor so I also generally pick mongo. Again, your mileage may vary! Welcome to HN!
- jordanchan 11y ago
  Ah, sure! Good that you brought it up. Such questions were actually considered, but the answers arrived at were always vague and changeable. Not surprising for a startup I guess. Much of it will be read heavy, some parts will be write heavy. "Ideally", we should be using different solutions for the different needs, but that's too much at the beginning. So the best bet will be the best balance, while avoiding a database/backend restructuring to the extent possible. How much data: not surprisingly, it will start small, and the upper limit depends on the future... Geographic based system, yes, eventually; but they both support geospatial. There will be time based queries for analytical and reporting purposes, not the core of the app. So that can easily be offloaded to a separate system. The structure of the data will be mostly relational, so we stick with one of the old school systems. For the little bits that will be either dynamic or non-relational, both MySQL and Postgres now support JSON. Popularity came into the equation because the more popular a system is, the more solutions are developed around it. So We won't be the first to tackle any problem in a popular system, thus reusing what others have done will be enough for the most part. Cheers!
  - deleted 11y ago
    [deleted]

trcollinson 11y ago

Oh no! The question isn't bad at all and this is the place to ask it! I don't mean to discourage you from asking on HN. What I mean by not asking those questions is when I am picking a system I usually ask other questions. Like: how much data am I going to be storing? What will he the structure of the data? Will I be heavy read, heavy write, or a mix of both? Will the data be pulled on a geographic or a time based system? Things like that. My requirements rarely worry about popularity. Also, again anecdotally, while it may seem like I endorse mysql, I actually prefer postgres. However, I am a big fan of meteor so I also generally pick mongo. Again, your mileage may vary! Welcome to HN!

jordanchan 11y ago
Ah, sure! Good that you brought it up. Such questions were actually considered, but the answers arrived at were always vague and changeable. Not surprising for a startup I guess. Much of it will be read heavy, some parts will be write heavy. "Ideally", we should be using different solutions for the different needs, but that's too much at the beginning. So the best bet will be the best balance, while avoiding a database/backend restructuring to the extent possible. How much data: not surprisingly, it will start small, and the upper limit depends on the future... Geographic based system, yes, eventually; but they both support geospatial. There will be time based queries for analytical and reporting purposes, not the core of the app. So that can easily be offloaded to a separate system. The structure of the data will be mostly relational, so we stick with one of the old school systems. For the little bits that will be either dynamic or non-relational, both MySQL and Postgres now support JSON. Popularity came into the equation because the more popular a system is, the more solutions are developed around it. So We won't be the first to tackle any problem in a popular system, thus reusing what others have done will be enough for the most part. Cheers!
- deleted 11y ago
  [deleted]