3 ms·

"This is not to deny that MongoDB offers some compelling advantages. Many users have found that they can get up and running on MongoDB very quickly, an area wh

by gdulli 13y ago

"This is not to deny that MongoDB offers some compelling advantages. Many users have found that they can get up and running on MongoDB very quickly, an area where PostgreSQL and other relational databases have traditionally struggled." A few things about this I've never understood. 1. Someone's going to make a technology decision with priority given to a one-time cost over the strengths and weaknesses of running competing products in perpetuity? The ability to avoid having to learn something is a pro in this decision? 2. If you don't have the skill set to install or maintain MySQL or Postgres, you should not be in charge of installing or maintaining production systems, period. You will hit your ceiling the first time you have to do anything non-trivial with a system that happens to have been easier to "get started with."

kristiandupont 13y ago
If you are building a system for a fortune 500 with a well defined purpose, that will run for years, your #1 might apply. But if you are building something new that you aren't sure what will become yet, like a startup, I would go with the thing that gets you up running the fastest. This allows you to validate quicker and then perhaps change if the project grows to require it. As for #2, I think that technology is now such a big field that this sort of argument is very rarely valid. NoSQL databases might be so young that there are no db admins with that as their primary field just yet, but that will change soon.
prawks 13y ago
That quote doesn't directly relate to either of your points. It's only pointing out that an advantage is that Mongo is easy to get set up and load data into quickly. In certain use cases, that advantage is important (rapid prototyping). In other cases, it's easily outweighed by things like the potential lifetime of the system and the needs associated with that. No one should make a decision on which tech to use by any one strength/weakness in isolation, and I don't think this article is promoting that mindset.
astalwick 13y ago
The critical point in the life of a startup is very often that short period at the start, when the team is small and stretched in a hundred directions, trying to 'execute' on everything at once. It's really important to choose your battles. Where I work (wavo.me), we went with MongoDB, and though imperfect, it was the right DB for us. It's quick to get going, and the schemaless document store makes it easy to change directions and iterate very quickly. That was (and still is) super important to us. It's really not about skillset, it's about cycles.
- gdulli 13y ago
  My point is that MySQL/Postgres aren't difficult and this is a pretty low-hanging fruit example of a decision that doesn't need to be made and shouldn't be made with short-term thinking. Maybe it's necessary at times, but you can go too far with that excuse. Code is much, much easier to change/fix than a data store.
  - threeseed 13y ago
    MySQL/Postgres aren't difficult but they are more complex that MongoDB. And in Agile you are taught to only focus on the short term and then move only when you need to. In which case picking the simpler database has merits.
    - nasalgoat 13y ago
      It's a case where your short-term choice leads to long-term pain if you actually succeed in your start up. Should you really be making short-term decisions like that if you're not planning to fail?
  - astalwick 13y ago
    Sure. Lots of factors go into deciding a data store, and you're right that you shouldn't just choose at random. I disagree with the implication that if you do actually think about it, you'll necessarily land on MySQL or Postgres. We landed on Mongo, and one of the reasons we did was because we were uncertain about the product direction. We knew we were going to be making massive changes to the schema. We didn't want to (couldn't) spend the time up front the think through the precise implications of every table in the system. In a very real way, we didn't even know what data we were going to be storing! So, we mostly skipped it. We came up with a simple set of documents, our best guess, and ran with that. We made mistakes (we knew we would), and we corrected them easily. We saved time up front, and really haven't regretted it at all.
- angrybits 13y ago
  In a non-trival application, using a schemaless document store doesn't relieve you of having a schema, especially in the face of a relationship change. You either have to write a migration to change all the records, which non-MySQL relational engines happen to be extremely good at, or you litter your ORM with a bunch of version specific nonsense.

by gdulli 13y ago

kristiandupont 13y ago

If you are building a system for a fortune 500 with a well defined purpose, that will run for years, your #1 might apply. But if you are building something new that you aren't sure what will become yet, like a startup, I would go with the thing that gets you up running the fastest. This allows you to validate quicker and then perhaps change if the project grows to require it. As for #2, I think that technology is now such a big field that this sort of argument is very rarely valid. NoSQL databases might be so young that there are no db admins with that as their primary field just yet, but that will change soon.

prawks 13y ago

That quote doesn't directly relate to either of your points. It's only pointing out that an advantage is that Mongo is easy to get set up and load data into quickly. In certain use cases, that advantage is important (rapid prototyping). In other cases, it's easily outweighed by things like the potential lifetime of the system and the needs associated with that. No one should make a decision on which tech to use by any one strength/weakness in isolation, and I don't think this article is promoting that mindset.

astalwick 13y ago

The critical point in the life of a startup is very often that short period at the start, when the team is small and stretched in a hundred directions, trying to 'execute' on everything at once. It's really important to choose your battles. Where I work (wavo.me), we went with MongoDB, and though imperfect, it was the right DB for us. It's quick to get going, and the schemaless document store makes it easy to change directions and iterate very quickly. That was (and still is) super important to us. It's really not about skillset, it's about cycles.

gdulli 13y ago
My point is that MySQL/Postgres aren't difficult and this is a pretty low-hanging fruit example of a decision that doesn't need to be made and shouldn't be made with short-term thinking. Maybe it's necessary at times, but you can go too far with that excuse. Code is much, much easier to change/fix than a data store.
- threeseed 13y ago
  MySQL/Postgres aren't difficult but they are more complex that MongoDB. And in Agile you are taught to only focus on the short term and then move only when you need to. In which case picking the simpler database has merits.
  - nasalgoat 13y ago
    It's a case where your short-term choice leads to long-term pain if you actually succeed in your start up. Should you really be making short-term decisions like that if you're not planning to fail?
- astalwick 13y ago
  Sure. Lots of factors go into deciding a data store, and you're right that you shouldn't just choose at random. I disagree with the implication that if you do actually think about it, you'll necessarily land on MySQL or Postgres. We landed on Mongo, and one of the reasons we did was because we were uncertain about the product direction. We knew we were going to be making massive changes to the schema. We didn't want to (couldn't) spend the time up front the think through the precise implications of every table in the system. In a very real way, we didn't even know what data we were going to be storing! So, we mostly skipped it. We came up with a simple set of documents, our best guess, and ran with that. We made mistakes (we knew we would), and we corrected them easily. We saved time up front, and really haven't regretted it at all.
angrybits 13y ago
In a non-trival application, using a schemaless document store doesn't relieve you of having a schema, especially in the face of a relationship change. You either have to write a migration to change all the records, which non-MySQL relational engines happen to be extremely good at, or you litter your ORM with a bunch of version specific nonsense.