Store aggregates: mongodb or postgres json

[crclz]

Hello, Mr VernonI.

I read the article "The Ideal Domain-Driven Design Aggregate Store?" at https://kalele.io/the-ideal-domain-driven-design-aggregate-store/
Now mongodb already supports ACID transactions (after 2018 summer).I wonder whether mongodb is capable of storing ddd in production environment or not.

I'm worried about performance.

https://docs.mongodb.com/master/core/transactions/ :

IMPORTANT
In most cases, multi-document transaction incurs a greater performance cost over single document writes, and the availability of multi-document transactions should not be a replacement for effective schema design.

https://www.mongodb.com/blog/post/multi-document-transactions

With subdocuments and arrays, document databases allow related data to be unified hierarchically inside a single data structure. The document can be updated with an atomic operation, giving it the same data integrity guarantees as a multi-table transaction in a relational database.

Because of this fundamental difference in data modeling, MongoDB’s existing atomicity guarantees are able to meet the data integrity needs of most applications. In fact, we estimate 80%-90% of applications don’t need multi-document transactions at all.

As you can see in this two articles written by mongodb official, the ACID transaction of mongodb is probably designed for some corner cases (probably 10% of 10% projects, I guess). But in DDD we use multi-document transactions frequently. ACID transaction is needed whenever we want to publish or handle a domain event.

So I'm worried that the way they design mongodb makes the transaction of mongodb not friendly with Domain Driven Design. But I cannot find benchmarks or some other articles about this topic. Would you please answer my question?

In addition, in https://kalele.io/the-ideal-domain-driven-design-aggregate-store/ , you said that postgres is very fast. I would like to know which one should be chosen to store aggregates (1) when db runs on single machine (2) when db is distributed