Ask HN: PostgreSQL or MySQL with Node.js?
1 comments
Are you using a specific back end framework or just plan old node?
I generally don't ask questions about databases like you are here but I have used both mysql and postgres with large node projects (as well as others!).
Popular: I would say this feels like a toss up. Both are pretty popular. I think they go back and forth on pure popularity. Both have strong communities. Mysql is "owned" by oracle so I guess you can take that into the popularity equation.
Easy to set up: again, a toss up. Both are relatively easy to set up initially. Both have a huge number of optional configurations depending on your needs. Anecdotally, mysql has a lot of engine options depending on needs. Out of the box, they are fairly similar on setup. Also fairly similar on node setup and configuration.
Scaling out: these are both RDBMS systems so scaling out is always an adventure. This has little to do with node and a ton more to do with your scaling needs. Both have the capability. Neither is easy.
I generally don't ask questions about databases like you are here but I have used both mysql and postgres with large node projects (as well as others!).
Popular: I would say this feels like a toss up. Both are pretty popular. I think they go back and forth on pure popularity. Both have strong communities. Mysql is "owned" by oracle so I guess you can take that into the popularity equation.
Easy to set up: again, a toss up. Both are relatively easy to set up initially. Both have a huge number of optional configurations depending on your needs. Anecdotally, mysql has a lot of engine options depending on needs. Out of the box, they are fairly similar on setup. Also fairly similar on node setup and configuration.
Scaling out: these are both RDBMS systems so scaling out is always an adventure. This has little to do with node and a ton more to do with your scaling needs. Both have the capability. Neither is easy.
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.
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.
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!
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!
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!
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]
Which is 1) more popular, 2) easier to setup, and 3) better for scaling out (not up)?