It's not just because of hype that teams choose Mongo.
The flexibility of a schemaless db is pretty helpful in a startup scenario, where the requirements drastically change all the time.
Yes, migrations work for RDBMS too, but with Mongo you only write migrations for data changes, not schema changes - which means a lot less migrations.
The option of having documents with embedded objects/lists makes it a pretty natural mapping to Domain Driven Design concepts, like aggregate roots + aggregates. One might even argue that while following DDD, it's preferable to handle most rules at the application layer and use the database simply as a performant, low-maintenance storage service. I know some folks here might view this approach as a sin, but it works pretty well too, especially for smaller teams without a dedicated DBA.
Maybe it's just me that haven't ran large enough systems to find the kind of issues with mongo that people always rant about, idk. Honest question: considering all these advantages above (from a developer's point of view), are there good reasons for choosing something like PostgreSQL over Mongo for typical business apps?
I'm not entirely convinced that MongoDB is better suited or a natural mapping to DDD concepts in practice, it's just more convenient for developers who want to build things fast.
My thoughts on this pattern are to still use a robust, reliable db (Postgres) behind a message queue for the event store. Postgres does almost all of the things I need with the reliability that I need while letting me sleep at night.
An event store absolutely must be the most reliable part of the infrastructure, IMO.
"just more convenient for developers who want to build things fast" - that's a compelling advantage for Mongo, isn't it?
I agree a robust, reliable db is super important - but isn't Mongo too, at this point? Even if it wasn't back in 2012? I thought most of the reliability issues and bad defaults were fixed by now...
My (in)experience with Mongo leaves me with a certain existential dread that I just can't shake. Also for that sort of thing these days I'd be more likely to use ElasticSearch than anything (this absolutely terrifies me actually, but I'm seeing companies do this) and eat the extra infrastructure expense. Serves the same function and gives me insanely powerful tools to process the data without having to write any code.
In my planning for problem domain changing, personally I'm going to be writing a (relational) schema for the new data model anyway, which will be Postgres, and playing my event store over it and doing one-way writes to it going forward anyway. I'd rather reduce the mental maintenance overhead of two different databases to one.
Interesting. I've always thought event store was an interesting pattern, but not something as a default architecture for typical business apps, probably because of the added complexity in maintenance.
If you're building your relational db based on the event store, I'd imagine even something simpler like Mongo would do it, but I agree that having a single db to maintain is an important advantage.
Schema migrations during rapid growth are usually of the ADD COLUMN type which is cheap & easy. Data migrations are about the same amount of effort either way. If anything, requiring explicit schema migrations forces you to think more carefully about your schema design decisions and saves headache down the road, as the article mentions Etsy (and many others) encountered.
Yes, migrations work for RDBMS too, but with Mongo you only write migrations for data changes, not schema changes - which means a lot less migrations.
The option of having documents with embedded objects/lists makes it a pretty natural mapping to Domain Driven Design concepts, like aggregate roots + aggregates. One might even argue that while following DDD, it's preferable to handle most rules at the application layer and use the database simply as a performant, low-maintenance storage service. I know some folks here might view this approach as a sin, but it works pretty well too, especially for smaller teams without a dedicated DBA.
Maybe it's just me that haven't ran large enough systems to find the kind of issues with mongo that people always rant about, idk. Honest question: considering all these advantages above (from a developer's point of view), are there good reasons for choosing something like PostgreSQL over Mongo for typical business apps?