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.
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.
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.
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.
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.
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.