Is MongoDB a good fit to track a stock portfolio? Is mongoDB or any document database in general a good fit to track a stock portfolio?

I have identified 5 main data domains:


Portfolios
Transactions
Holdings
Stocks information
Stock Prices


The holdings are just the combined view of all the transactions and are therefore derivable from the transaction history. Every time a transaction is updated, created, deleted, the holdings change.

It seems to be the most challenging part.

In a RDBMS, we could use triggers or views to work around this but I am not sure what we could do on MongoDB and if there is a good solution?
The "Stocks information" domain potentially fits well with a document database, such as MongoDB. The information available for different financial instruments might vary substantially, which means that a loose schema and the ability to store in-depth information in loosely defined sub-document structures could be useful. Also, you may want to extend the information scope gradually over time, in directions that may be hard to anticipate, which could be another argument in favor of a loose schema for the storage.

However, the other four data domains are typical examples of what a relational database is optimized for. While there may perhaps exist other, less widely used document databases that provide sufficient integrity constraint and join functionality to work well in this scenario, MongoDB certainly does not.

If the data really must be stored in MongoDB, the best would probably be to put all portfolio, transaction and holding information of each owner, along with cached price data for relevant instruments, in a single document. The application would then handle all necessary calculations when a stock owner makes a transaction, which would already be more complicated than achieving the same thing using built-in functionality for triggers, constraints and views in relational databases, but could, with some effort, be made to work reliably and with reasonable performance.

Once data for several owners must be aggregated, or when already loaded price information has been determined to contain errors, requiring all ownership documents to be recalculated, you will, however, have to spend even more time doing things that would be trivial with a relational database solution. Performance is also likely to be worse.

If there are strong other reasons to use a document database, and a solution with two concurrent database types is not acceptable, it might be worth the trouble to use MongoDB, but otherwise, a relational database will be the easiest and most robust solution.

Also, there are now relational databases with reasonably good document storage functionality. Microsoft SQL Server, for example, has JSON column support since version 2016, with query support for document content that could be sufficient for fairly complex document-based financial instrument information models.