Joins between Read Models introduces the need for transactions

Usually, Read model data is self-contained and preserved in a denormalized form. The information itself is usually ready-to-ship in response to a query from a user-facing application or external system. This type of data structure makes document databases a good fit for storing Read Model data.

But you can undermine this solution's effectiveness by compromising on the autonomous nature of Read Model data. By spreading the data across multiple objects (tables or documents depending on the type of database), you can accidentally introduce the need for transactions without a business need for them.

Linked Read Models have to be updated in a single transaction to prevent partial reads across the application. Also, if there is a chance that multiple read models are updated concurrently, transactions are necessary to prevent lost updates due to dirty writes. The application will thus have to depend on the database's transaction support to function correctly.

For these reasons, it is best to keep Read Models autonomous.

Even if you are storing Read Model data in a relational database today, it is best to keep them independent to retain the option of moving to a different database later.